TypeScript Interview Questions and Answers for 2025

The TypeScript language is divided internally into three layers namely Language, TypeScript Compiler, and TypeScript Language Services. These layers are further broken down into components.

• Language: It is written in TypeScript and contains elements of the TypeScript language. It incorporates annotations for type, syntax, and keywords. 
• The TypeScript compiler (TSC): A TypeScript program is converted into JavaScript code via the TypeScript compiler (TSC). It also parses and type-checks our TypeScript code prior to converting it into JavaScript code. 
  
• The TypeScript Language Services: Provides information that enables editors and other tools to offer more powerful help features like automated refactoring and IntelliSense. The core-compiler pipeline gains an additional layer of abstraction as a result. It provides features like statement completion, colorization, signature assistance, and code formatting and outlining. 

A common question in interview questions on TypeScript, don't miss this one.  

Although the null and void data types in TypeScript initially appear to be quite similar, they are kept distinct for strong reasons. TypeScript has these two data types for their unique purposes, such as 

Void 

The void data type indicates the absence of a type on a variable, it acts as a reverse of “any” data type. It is particularly helpful in functions that don't return a value. However, declaring variables as void is not especially useful since, if —strictNullChecks is not used, you can only assign undefined or null values to void-type variables.

A function in JavaScript that doesn't explicitly return anything defaults to returning undefined. TypeScript infers that these functions have a void return type.

const greet = (name: string) : void => { 
 console.log(`Hello ${name}`} 
}  

Never 

The "never" type denotes values that never arise. It can be used with functions that never return or with those that consistently throw exceptions.

Moreover, when a type guard is applied for narrowing, TypeScript additionally infers the value is "never" data type if that value can never be true,

const example = (val: string | number) => { 
 if (typeof val === 'string') return val.substr(-2); 
 if (typeof val === 'number') return val.toLocaleString(); 
 else {console.log(val) // val is inferred as "never" 
 } 
} 

let f = () => { 
 throw new Error("Should never get here"); // infers as () => never 
} 
 
let g = function() {  
 throw new Error("Should never get here"); // infers as () => never 
} 
 
function h() {  
 throw new Error("Should never get here"); // infers as () => void 
} 

The three functions are inferring different return types because TypeScript interprets function declarations and function expressions with arrow functions differently. 

When a function is marked as throw-only, it receives the type never for expressions and void for declarations, respectively. Thus the difference arises because f and g are function expressions, where h is a function declaration. 

For instance, let us consider the code below,

function doIf(value: boolean, 
  whenTrue: () => number,  
  whenFalse: () => number): number { 
  return value ? whenTrue() : whenFalse(); 
} 
let x = doIf(2 > 3, 
 () => { throw new Error("haven't implemented backwards-day logic yet"); }, 
 () => 14);

When we think a function should not be called or should only be invoked in error situations, it is typical to write a throwing function. But the call to doIf() will be declined if the type of function expression is void.

This example makes it quite evident that function expressions that only throw should actually return never and not void. And frankly, given that these functions are never, this should be our underlying assumption because, in a correctly-typed program, a value of never data type cannot be observed.

Now the question is why don't all throwing functions never return data type? The quick answer is that doing so turned out to be a big mess. There are many programs mostly the code predating the abstract keyword is written like this.

class Base { 
 overrideMe() { 
 throw new Error("You forgot to override me!"); 
 } 
} 
 
class Derived extends Base { 
 overrideMe() { 
 // Code that actually returns here 
 } 
}  

However, a function that returns void cannot be used in place of a function that returns never. As a result, Derived cannot provide any non-never implementation of that function if Base.overrideMe() returns never. 

Function declarations that always throw are extremely uncommon, although function expressions that always throw frequently appear as a kind of placeholder for Debug.fail().

Declarations are static, whereas expressions frequently get aliased or ignored. In the absence of a return type annotation, it is better to supply void rather than never for a function declaration. Since a function declaration that throws now is actually likely to perform anything valuable tomorrow. 

One of the most frequently posed TypeScript interview questions, be ready for it.  

A variable's type can occasionally change depending on its input. Conditional types change a variable's type in accordance with a preset condition, bridging the type gap between the input and output. An essential TypeScript feature called conditional type helps in the creation of type-safe framework-like code, such as API boundaries.

In TypeScript, conditional types resemble the ternary operators we have in JavaScript. As the name implies, a conditional type selects one of two potential types for the variable based on a condition provided as a type relationship test.

The conditional types are written like this.

condition ? X : Y

Here the type Type X is used if the condition is true whereas type Y is applied if the condition fails. For example

interface Animal { 
 live(): void; 
} 
interface Dog extends Animal { 
 woof(): void; 
} 
type example = Dog extends Animal ? number : string;  
console.log(typeof example) // number

A staple in TypeScript interview questions, be prepared to answer this one.  

Distributive conditional types are conditional types in which the checked type is a union-type parameter. When conditional types act on a generic type, they become distributive if the type parameter is of union type. In other words, if we pass a union type as the checked type, then the conditional type will be applied to each member of that union.

Distributive conditional types are automatically distributed over union types after instantiation. For example

type getType<Type> = Type extends U ? X : Y; 
type newType = getType<A | B | C> 

Here, the newType is resolved as

type newType = (A extends U ? X : Y) | (B extends U ? X : Y) | (C extends U ? X : Y)

Distributivity is typically the desired behaviour. Albeit, you can use square brackets to enclose the extends keyword on each side to prevent that effect. For example:

type ToArray<Type> = Type extends any ? Type[] : never; 
  
type StrArrOrNumArr = ToArray<string | number>; // resolves as type StrArrOrNumArr = string[] | number[] 
 
 
// add square brackets to prevent Distributivity 
type ToArrayNonDist<Type> = [Type] extends [any] ? Type[] : never; 
  
type StrOrNumArr = ToArrayNonDist<string | number>; // resolves as type StrArrOrNumArr = (string | number)[] 

You can organize your code in TypeScript by using namespaces. Namespaces in TypeScript were formerly known as internal modules, they are based on an earlier edition of the ECMAScript modules. Around September 2013, internal modules were dropped from the ECMAScript specification, however, TypeScript retained the concept under a different name.

Namespaces give programmers the ability to establish independent groups that can be used to store a single or a collection of related functionality, such as properties, classes, types, and interfaces.

namespace DatabaseEntity { 
 class User { 
 constructor(public name: string) {} 
 } 
 
 const user1 = new User("Jon"); 
}  

The absolve code works fine, but if you try to use the User class outside the DatatbaseEntity the TypeScript compiler will give you an error.

Property 'User' does not exist on type 'typeof DatabaseEntity'

You must export the User class in order for it to be accessible outside of your namespace if you wanted to utilize it elsewhere.

namespace DatabaseEntity { 
 export class User { 
 constructor(public name: string) {} 
 } 
 
 const user1 = new User("Jon"); 
} 
 
const user2 = new DatabaseEntity.User("Jane"); 

The three JSX modes that are by default bundled with TypeScript are preserve, react, and react-native. 

• Preserve: The JSX output of your code can be customized using these modes. The preserve mode's goal is to keep the JSX output within your compiled code so that another compiler can directly operate on it.
• React-native: The compiler will create a file with a .jsx file extension while this mode is active so that it can be further modified before usage. Similar functionality is provided by the react-native mode, however, the emitted output file will have the .js file extension. 
• React: React mode functions a little differently. Because it omits the React.createElement modifier, the result is devoid of raw JSX code. When utilising this mode, the output file will have the .js file extension. 

Yes we can use a JSX file in a TypeScript project, however, your TypeScript file must be saved with the a.tsx extension. On a default level, TypeScript comes with three JSX modes preserve, react, and react-native namely.

But there are a few important things to keep in mind while working with JSX and TypeScript in your project. Since JSX has an embeddable XML-like syntax, it must be compiled into valid JS. Thus, to ensure that y our code will now go through more compilation steps, which could affect the performance of your program.

On the other hand, TypeScript offers a number of powerful tools, such as type verification, embedding, and direct JSX compilation, for an enhanced working experience with JSX.

We cannot inherit or extend from more than one class in TypeScript, but Mixins allow us to circumvent this limitation. Mixins encourage reusability and assist you in avoiding the limitations imposed by multiple inheritances.

Mixins produce partial classes that we may combine to create a single class that contains all of the methods and properties from the partial classes. Moreover, Mixins provide the ability to postpone the declaration and binding of methods until runtime, even while attributes and instantiation arguments are defined at compile time.

To construct a mixin, we will use two TypeScript features: interface class extension and declaration merging. TypeScript uses interface class extension to extend multiple classes. And declaration merging is the method used by TypeScript to combine two or more declarations with the same name.

For example, let us create a base class (to which the mixins will be applied) and two contractor classes (to which the base class will extend).

// constructor classes 
class CanFly { 
 fly() { 
 console.log(“flying”) 
} 
} 
  
class CanWalk { 
 walk() { 
 console.log(“walking”) 
} 
} 
  
// base class 
class Bird { 
 x = 0; 
 y = 0; 
} 

Create an interface that merges the expected classes with the same name as your base class (Bird). Due to declaration merging, the Bird class will be merged with the Bird interface.

interface Bird extends CanFly, CanWalk {}

Next, create a function to join two or more class declarations.

function applyMixins(derivedCtor: any, constructors: any[]) { 
 constructors.forEach((baseCtor) => { 
 Object.getOwnPropertyNames(baseCtor.prototype).forEach((name) => { 
 Object.defineProperty( 
 derivedCtor.prototype, 
 name, 
 Object.getOwnPropertyDescriptor(baseCtor.prototype, name)  || Object.create(null) 
 ); 
 }); 
 }); 
} 
applyMixins(Bird, [CanFly, CanWalk]);

Here, the applyMixins() function iterates through the CanFly and CanWalk classes, then loops through their list of properties and adds those properties to the Bird class.

Now the Bird instance can directly access the walk() and fly() methods from the CanSwim and CanFly classes, respectively. For example: 

 let bird = new Sprite(); 
bird.fly(); // flying  

A Type Declaration or Type Definition file is a TypeScript file with the.d.ts file extension. As the name implies, a type declaration file only includes type declarations and not actual source code (program logic). These files are not intended to be included in the compilation itself; rather, they are primarily intended to help with the development process.  

Using these declaration files with TypeScript comes with the following two drawbacks: 

• When you upgrade TypeScript, you also need to deal with modifications to TypeScript's built-in declaration files, which can be challenging given how frequently the DOM APIs change. 
• It is challenging to modify these files to suit your goals and the requirements of your project's dependencies. For example, you might be compelled to use the DOM APIs if your project dependencies use it.

In TypeScript, the Function is a global type. Along with the other attributes found on all function values, it has properties like bind, call, and apply. It also has the unique quality of always being able to call values of type Function, and these calls can return a value of “any” data type.

function doSomething(f: Function) { 
 return f(1, 2, 3); 
}  

However this is an untyped function call and is typically advised to avoid because of the unsafe “any” return type. 

In general, if you need to accept any function but are not planning to call it, the type () => void is a safer approach than the Function data type. 

function doSomething(f: () => void) { 
 return f(1, 2, 3); 
}

doSomething(() => { 
console.log(‘function called”) 
}) 

TypeScript has a number of globally available utility types that simplify common type transformations. Here are a few of TypeScript's most useful utility types.

Pick<Type, Keys>

The Pick utility type generates a new type by selecting the set of Keys attributes from Type, where Keys may be a single string literal or a union of string literals. The keys of the Type must be the value of Keys for the TypeScript compiler to not raise an error. This utility class is extremely helpful when you wish to make objects lighter by selecting particular properties from objects with many properties.

Omit<Type, Keys>

The Omit utility type is the opposite of Pick because it specifies a collection of properties to be omitted rather than a collection of properties to keep. It is more practical when you simply want to remove a few attributes from an object while keeping others.

Partial<Type>

The Partial utility type creates a type by setting all Type properties optional. When composing an object's update logic, it can be really helpful.

Required<Type>

Unlike Partial, the Required utility type accomplishes the opposite. It creates a type with all the properties of the Type set to mandatory. It can be applied to make sure a type doesn't have any optional properties.

Readonly<Type>

With the Readonly utility type, you can create a type with all of Type's properties set to read-only. Its variable and properties will issue a TypeScript warning if new values are assigned to them.

One of the most frequent causes of unanticipated runtime problems in programming is null pointers. By requiring stringent null checks, TypeScript greatly assists you in avoiding them. 

Here are the two main methods that you can use to enforce strict null checks in TypeScript: 

• By passing the —strictNullChecks flag to the TypeScript (tsc) compiler. 
• By updating the value of the strictNullChecks field in the tsconfig.json configuration file to true 

The code in TypeScript ignores null and undefined values when the flag —strictNullChecks is set to false. When this flag is true, null, and undefined both have their unique types, respectively. Hence, if you try to utilize them in a situation where a concrete value is anticipated, the compiler will throw a type error.

Intersection types work similarly to Union types in TypeScript, it empowers you to combine the type of two or more unique types by using the ‘&’ operator. Hence it can be used to combine diverse types in your project to create a new type with all the properties you require. For example:

type Combined = { a: number } & { b: string }; 

In case, both combining types have a property of same name but different type. Then, that property will have an intersection of the two properties in the resultant type.

type Conflicting = { a: number } & { a: string }; 
// Conflicting = { a : number & string } 

When you intersect types, the order of the types is not to be concerned. For example, the typeBothAB and the typeBothBA have all the properties of the two types typeA and typeB i.e.typeBothAB and the typeBothBA have the same type definition. 

type typeBothAB = typeA & typeB; 
type typeBothBA = typeA & typeB; 

The Record type is one of the many powerful utility types available in TypeScript for the transformation of types. When attempting to build more sophisticated types of data, the Record Type is an excellent approach to guarantee consistency. It enforces key-value pairs and allows you to define custom interfaces.

Record<Keys, Type>

The Record utility type creates an object type from property keys in Keys whose corresponding values are of Type.

For example, let’s define an interface DogInfo with age and number properties. We can use the Record utility type to define the type of the dogs object with the dog names as key and the respective dog information object as its value.

interface DogInfo { 
 age: number; 
 breed: string; 
} 
  
type DogName = "pluto" | "scooby" | "rocky"; 
  
const dogs: Record<DogName, DogInfo> = { 
 pluto: { age: 10, breed: "Labrador" }, 
 scooby: { age: 5, breed: "German Shepherd" }, 
 rocky: { age: 16, breed: "Pitbull" }, 
};

A common question in interview questions on TypeScript, don't miss this one.  

Triple-slash Directives are single-line comments that include an XML element tag in them. Similar to double-slash comments in JavaScript and TypeScript, Triple-slash directives can be used to write comments although they are a lot more powerful and can also provide instructions for your compiler. 

Triple-slash directives only execute when they are at the top of the enclosed file. You can write comments before them, including additional triple-slash directives. However, if they come after any other kind of statement or declaration, your compiler will consider them as standard comments and ignore them.

/// <reference path="..." /> : Adding this to the beginning of your TypeScript code informs your compiler that there are file dependencies in the program. The compilation process will subsequently incorporate these extra files thanks to your compiler.

/// <reference types="..." /> : This is also similar to the path triple-slash directive, but instead of file dependencies, it informs the compiler about the package dependencies in the program.

/// <reference lib="..." /> : This also works similarly to the above two but is used for including the built-in lib file in your program. 

One of the most frequently posed TypeScript interview questions, be ready for it.  

Declarative merging in Typescript refers to the process by which the compiler creates a single definition out of several declarations with the same name. To improve the efficiency of your code, the TypeScript compiler combines (or merges) these declarations into a single definition. 

This merged definition will retain the characteristics of the original definitions from which this was constructed. All entities, including interfaces, namespaces, enums, and other objects, can be combined, excluding the classes.

For instance, here is a Typescript code with multiple interfaces with the same name

interface Animal {  
 doSomething(something: Fly): Fly  
}  
interface Animal {  
 doSomething(something: Jump): Jump 
}  
interface Animal {  
 doSomething(something: Run): Run  
}  

The typescript compiler will merge the three definitions from the above code into a single definition like this:

interface Animal { 
 doSomething(something: Fly): Fly  
 doSomething(something:Jump): Jump 
 doSomething(something: Run): Run 
}  

A staple in TypeScript interview questions, be prepared to answer this one.  

In TypeScript, the declare keyword is utilized as the prefix for the Ambient declaration of variables and methods. The declare keyword tells the TypeScript compiler that the concerned entity exists in the global scope and can be used inside your code. 

It works similarly to an import keyword, ambient declarations inform the compiler about the source code that is stored elsewhere in a different file. In order to use third-party libraries like JavaScript, jQuery, Node, etc., we generally utilize Ambient declarations in TypeScript. The declare keyword reduces the likelihood of errors in our TypeScript code by directly integrating these packages. The typical location for ambient declarations is a type declaration file with the '.d.ts' extension.

We can use the declare prefix to declare: 

• variable (const, let, var). 
• type or an interface 
• class 
• enum 
• function 
• module 
• namespace,

For instance, you want to use an API script in your TypeScript code. First, you must provide access to the API link on your HTML page.

<script async src="https://www.someAPI.com/gtag/js?id=TAG_ID"></script> 
<script> 
 window.dataLayer = window.dataLayer || []; 
 function gtag(){dataLayer.push(arguments)}; 
 gtag('js', new Date()); 
 
 gtag('config', 'TAG_ID'); 
</script>  

In your HTML, the dataLayer array is declared. However, your TypeScript programme does not know about it. If you wish to utilize the dataLayer array, you must declare it in a .d.ts file.

declare const dataLayer: any[]; 

Similarly, to use any other external code, we must declare it first and inform the TypeScript Compiler. For example: 

declare module '*.png' { 
 const src: string; 
 export default src; 
} 
declare function greet(hello: string): void; 

We should be cognizant that the ambient declarations occasionally lead to problems because your compiler will produce an error if the source changes. Thus, to prevent such errors if the location of your external source code changes, you must update all of your ambient declarations.

TypeScript definition Manager or TSD is a file package manager for TypeScript that allows you to easily download and install definition files to use in TypeScript projects. TSD makes it very easy to find and install TypeScript definition files of many public APIs, libraries, etc. from the free and open-source DefinitelyTyped repo. 

TSD is quite helpful because it enables you to use type definition files directly in your TypeScript code. For instance, you could use the following syntax to add some jQuery code to your.ts file:

$(document).ready(function() { //Your jQuery code });

Your compiler will inform you that it cannot locate the name "$", due to the fact that this type is a part of jQuery. You may use TSD to locate and download the jQuery Type Definition file, which you can then include in your.ts file, and your compiler will have everything it requires. 

It's no surprise that this one pops up often in Angular TypeScript interview questions.  

Your code can benefit from comprehensive inspections and more precise tooling thanks to TypeScript's strictness settings. The more you tweak your parameters, the more rigorously TypeScript evaluates your code. There are a number of type-checking flags available in TypeScript that can be turned on or off. The two most crucial to remember are:

• noImplicitAny: TypeScript assigns any type whenever we don't define a specific type in our code. If this flag is set to true, variables whose type is implicitly assumed to be any will produce an error. This flag is mainly useful because using the type any negates the purpose of adopting TypeScript over JavaScript in the first place.

We add the following code in our tsconfig.json, to mark the noImplicitAny flag true in our TypeScript project.

{ 
 "compilerOptions" : { 
 "noImplicitAny" : true 
 } 
} 

• strictNullChecks: This flag makes the handling of null and undefined data more explicit and rigorously verifies that we are handling all the null and undefined variables in our TypeScript code. When the strictNullChecks is false, the typescript compiler ignores the null and undefined values, this can throw unexpected errors at runtime. Whereas when the strictNullChecks is true, the typescript compiler handles the null and undefined as their own unique types. Thus, it will show a type error if you try to use them where a concrete value is expected. 

Use the following code in your tsconfig.json to mark strictNullChecks as true.

{ 
 "compilerOptions" : { 
 "strictNullChecks" : true 
 } 
}  

{ 
 "compilerOptions": { 
 "outDir": "./built", 
 "allowJS": true, 
 "target": "es5" 
 }, 
 "include": ["./src/**/*"] 
  
}  

The code snippet is taken from the tsconfig.json file, which is found at the root of every TypeScript project. It is used to administer the project's settings, including which files to include and what kinds of checking we want to conduct, among other things. 

• compilerOptions - This comprises the majority of TypeScript's configuration choices and gives us control over how the language should operate internally. Additionally, the code snippet also illustrates some of the various settings that are available inside it. 
• "outDir": "./built" - When this key is provided, the compiler will push the output file (production code files) into the directory listed in this key's value. This piece of code tells the computer to "emit all of the output files in the built folder." The project will be organized as follows. 

├── built 
│ └── index.js // output .js file 
├── index.ts // input .ts file 
└── tsconfig.json  

Unless otherwise provided, the compiler will produce output.js files in the same directory as the input.ts files, such as:  

src 
├── index.js 
└── index.ts  

• "allowJS": true - This boolean code allows us to also use JavaScript files as our input files along with .ts files in our typescript project. Since here the boolean is true, this key allows .js files to be imported inside our project instead of just .ts and .tsx files. The following code will cause an error if this key is set to "false":  
  

// greetings.js 
export const morningGreeting = "Good Morning"  

// index.ts 
import { morningGreeting} from "./greetings" 
console.log(morningGreeting) 

• "target": "es5" - This line of code directs the translation of the program written in more recent JavaScript syntax into the syntax of an earlier version, such as ECMAScript 5 ("es5"). 
• "include": ["./src/**/*"] - This expression essentially means to read in any files it understands from the src directory. Here the “include” key simply defines a list of filenames or regex patterns.

In TypeScript, decorators are declarations that can be attached as a prefix to class declarations, methods, accessors, properties, or parameter declarations. They are written as a "@expression," and evaluate some function that gets invoked during the runtime. 

In the question, a class decorator is declared just above a class declaration. This decorator will use the class constructor as its target and is usually good to observe, modify or replace the class declaration. 

Although Decorator Factories are functions that return another function and do not actually implement the decorator, the returned function oversees doing so and should assume the responsibility of a wrapper function.

In the question, we have a class decorator `someDecorator`, by using a decorator factory, we can write it as:

const someDecorator = function (canSwim: boolean) { 
 return (target: Function) => { 
 // some function logic 
 console.log(`The animal ${canSwim ? ‘can’ : ‘cannot’} swim`) 
 } 
}

The decorator ‘someDecorator’ takes one parameter and returns another function that implements the decorator itself. The value of the boolean parameter (either true or false) can now be passed to a Person class as follows:  

const someDecorator = function (canSwim: boolean) { 
 return (target: Function) => { 
 // some function logic 
 console.log(`The animal ${canSwim ? 'can' : 'cannot'} swim`) 
 } 
} 
 
@someDecorator(true) 
class Animal {}  

// calculate.ts 
declare module CalculateModule { 
 export class Maths { 
 doSubtract(numA: number, numB: number): number; 
 } 
} 
 
// main.ts 
var maths = new CalculateModule.Maths(); 
maths.doSubtract(12, 5) 

In the given program files, we are using the `Ambient` declaration, which informs the compiler that the actual piece of code exists elsewhere at a different file location. To write an Ambient declaration we use the following syntax:

declare module moduleName { 
// module data 
}  

Thus, the code sample provided to us in the question is coming from the module "CalculateModule," which exports the "Maths" class. The “Maths” class contains “doSubtract()” function which accepts two parameters numA and numB of the number type and returns a number.

This Ambient declaration is now being used in the Main.ts file when we construct a new instance maths of the Maths class. Maths.doSubtract(12, 5) will return 7 as 12 - 5 = 7 as the result of main.ts.

{ 
 "typeAcquisition": { 
 "enable": false 
 } 
}  

The above code shows TypeScript's Type Acquisition functionality, which is only required for JavaScript projects. In the configuration, we are deactivating the type acquisition for JavaScript projects by setting the 'enable' value to 'false'.

Typically, we must explicitly include the types in our TypeScript projects. However, the TypeScript tooling downloads all the types of modules we use in the background for JavaScript projects. The other "typeAcquisition" properties available in TypeScript are as follows: 

• include - Using this, we define an array containing all the types we want to utilize in our project from the DefinitelyTypes. For instance:

{ 
 "typeAcquisition": { 
 "include": ["jquery", "jest"] 
 } 
}  

• exclude - Here, this provides the option to turn off type-acquisition for a specific module or an array of modules in JavaScript projects. For instance:

{ 
 "typeAcquisition": { 
 "exclude": ["mocha"] 
 } 
}  

• disableFilenameBasedTypeAcquisition - This is a boolean that controls whether TypeScript should use the filenames available in the project to infer what types should be added. This is how we can incorporate it:

{ 
 "typeAcquisition": { 
 "disableFilenameBasedTypeAcquisition": true 
 } 
} 

In version 4.7 of TypeScript, it introduced the triple-slash directives to contain the resolution-mode attribute. This is how it appears syntactically:

/// <reference types="pkg" resolution-mode="require" /> 
// or 
/// <reference types="pkg" resolution-mode="import" /> 

Previously, the mode of containing files and the syntax we employed determined how imports were resolved in the project when utilizing Node's default ECMAScript resolution. However, using "resolution-mode," we are now able to refer to the types of CommonJS modules from an ECMAScript module or vice-versa.

Additionally, you may use "import type" to define an import assertion like: 

// Resolve `pkg` as if we were importing with a `require()` 
import type { TypeFromRequire } from "pkg" assert { 
 "resolution-mode": "require" 
}; 
 
// Resolve `pkg` as if we were importing with an `import` 
import type { TypeFromImport } from "pkg" assert { 
 "resolution-mode": "import" 
}; 
 
export interface MergedType extends TypeFromRequire, TypeFromImport {}  

interface Form<T> { 
 values: T; 
 errors: any; 
} 
 
const contactForm: Form<{name: string; email: string}> = { 
 values: { 
 name: "John", 
 email: "john@email.com" 
 }, 
 errors: { 
 emailAddress: "Invalid email address." 
 } 
}  

The code given to us in the question employs a generic Form interface and uses this interface as the type of the contactForm variable. However, the errors property in the contactForm refers to a field with the wrong name. It should be “email” as defined in the Form interface, instead of the current “emailAddress” property. Hence here is the fixed program:

interface Form<T> { 
 values: T; 
 errors: any; 
} 
 
const contactForm: Form<{name: string; email: string}> = { 
 values: { 
 name: "John", 
 email: "john@email.com" 
 }, 
 errors: { 
 email: "Invalid email address." 
 } 
} 

Because the errors property's type is set to any on the Form interface, we do not get a type error. There will be no type-checking as the consequence. We utilize the type 'any' whenever we do not want a specific value to result in type-checking issues.  

The Map TypeScript file in your TypeScript project converts the human-unreadable trans-compiled JavaScript back to readable TypeScript format. This is useful when debugging is required during production because the source Map will be used. 

In Typescript, most commonly there are two kinds of .map files, namely Source Map (.js.map) and Declaration Map (.d.ts.map). 

Source Map (.js.map):  

Each section of your generated JavaScript code is linked to the exact line and column of the corresponding Typescript file using JSON-formatted mapping definitions found in source map (.js.map) files.

When source maps are enabled, Visual Studio Code and Chrome DevTools will display your Typescript code during debugging rather than the generated complex and intricate JavaScript code. 

Declaration Map (.d.ts.map).:  

Declaration source maps (.d.ts.map) files include mapping definitions that connect each of the type declarations created in.d.ts files back to your original source file (.ts). The mapping definitions in these files are in JSON format.

This is helpful in code navigation when you have split a big project into small multiple projects using project references. You can utilize code editor tools like "Go to Definition" and "Rename" to traverse and edit code across subprojects in a transparent manner. 

When dealing with class members, TypeScript utilizes a variety of access modifiers. The access modifier makes the class members more secure and protects them from unauthorized use. It can also be used to manage a class's data members' visibility.  

There are three distinct access modifiers in TypeScript: 

• public: A class that is public can be accessed by all of its members, including its child classes and class instances. 
• private: Private denotes that a class's members can only access one another. 
• protected: When a class is marked as protected, all of its members and the members of its children classes can access it, but the class instance cannot. 

When there is no access modifier before a class member in the code, TypeScript automatically applies the public access modifier to all members of the class. This might cause problems with compliance processes, thus you should explicitly define the access behavior whenever possible.

Furthermore, after your TypeScript code has been compiled, class modifiers have absolutely no impact on your final JavaScript code. Since these modifiers are only present in typescript and not taken into account when the compiler generates the final JS. 

It is common practice to modify an existing type by making each of its properties optional. Given how frequently this occurs in JavaScript, TypeScript offers a feature called mapped types that enables you to define new types based on pre-existing ones. In a similar fashion, the new type converts each property of the old type into a mapped type. For instance, you may make all properties read-only or optional.

A mapped type is a generic type that builds types by iterating through keys using a union of PropertyKeys, which are commonly constructed using "keyof" keyword.

For instance, OptionsFags<Type> is “Mapped type,” it is a generic type that takes a type of parameter and iterates over its members to declare the same member's name properties of the boolean type.

type OptionsFlags<Type> = { 
 [Property in keyof Type]: boolean; 
}; 
 
type FeatureFlags = { 
 darkMode: () => void; 
 newUserProfile: () => void; 
}; 
  
type FeatureOptions = OptionsFlags<FeatureFlags>;  

Here, the FeatureOptions type copies and define properties of boolean type for all the corresponding member names of FeatureFlags.   

type FeatureOptions = { 
 darkMode: boolean; 
 newUserProfile: boolean; 
} 

To ensure that TypeScript and JavaScript support performs commendably out of the box, TypeScript includes a number of declaration files (.d.ts files). These declaration files contain information on the various JavaScript APIs as well as the DOM APIs that are common across all browsers. You can adjust the lib setting in the tsconfig.json to specify which declaration files your project needs, albeit there are some reasonable defaults based on your target.

Similar to @types/ support, TypeScript includes a feature that lets you override a particular built-in library. When deciding which lib files to include, TypeScript will look for a scoped @typescript/lib-* package in node modules. Next, you may use your package manager to install a specific package to substitute for a specific one.