Unit 5: TypeScript Fundamentals - Practice Quiz

TypeScript's main feature is its static type system, which helps catch errors during development before the code is run, leading to more robust and maintainable applications.

TypeScript was created and is actively maintained by Microsoft. It was first released to the public in October 2012.

Browsers cannot execute TypeScript directly. The TypeScript compiler (tsc) transpiles TypeScript (.ts) files into standard JavaScript (.js) files that any browser can understand and run.

In TypeScript, type annotations are done using a colon (:) followed by the type name after the variable identifier.

The boolean type is a primitive type in TypeScript that can only have two values: true and false.

The type keyword is used to declare a type alias, which can give a new name to any type, including primitives, unions, intersections, and objects.

An interface is a way to define a contract for an object's shape, specifying the names and types of its properties and methods.

The pipe character | is used to create a union type. For example, string | number means the variable can hold either a string or a number.

Type inference allows you to omit type annotations in certain cases because the TypeScript compiler is smart enough to figure out the type on its own, for example let x = 10; infers that x is of type number.

Standard TypeScript files use the .ts extension. Files that contain JSX syntax (used with frameworks like React) use the .tsx extension.

The any type is an escape hatch that tells the compiler to not perform any type checks on a value. Its use is generally discouraged in favor of more specific types.

Generics allow you to write reusable functions, classes, and interfaces that are type-safe and can operate on different data types, which are specified when the component is used.

Because the variable score is initialized with the numeric literal 100, TypeScript's type inference system automatically assigns it the type number.

An intersection type (&) combines multiple types. A value cannot be both a string and a number at the same time, so this type is impossible to create. TypeScript represents impossible types with the never type.

T is a conventional placeholder name for a generic Type parameter. While any valid identifier can be used, T is a widely accepted convention.

TypeScript is a statically typed language. This means that variable types are known and checked at compile-time, before the code is executed.

The presence of a tsconfig.json file in a directory indicates that the directory is the root of a TypeScript project. It specifies compiler options and files to include.

This is a form of type narrowing. For a variable of a union type like string | number, using if (typeof myVar === 'string') tells the compiler that inside that if block, myVar is guaranteed to be a string.

A class can declare that it adheres to the contract of an interface by using the implements keyword. The class must then provide an implementation for all the properties and methods defined in the interface.

TypeScript offers two equivalent syntaxes for defining arrays: number[] (postfix syntax) and Array<number> (generic syntax). Both declare a variable that must hold an array of numbers.

While TypeScript does transpile code (similar to Babel), its main purpose is to add a static type system on top of JavaScript. This helps catch common errors like typos, incorrect function arguments, and null pointer exceptions before the code is even run, which is invaluable for large-scale application development and team collaboration.

The unknown type is a type-safe counterpart to any. You cannot perform any operations on a value of type unknown without first performing a type check or assertion to narrow its type. The compiler correctly identifies that the toUpperCase method may not exist on data and throws a compile-time error.

A significant difference is that interfaces are 'open' and can be extended through declaration merging. If you declare the same interface multiple times, TypeScript will merge their properties. type aliases, on the other hand, create a named alias for a type and cannot be redeclared or merged.

An intersection type (&) combines multiple types into one. An object of type AdminUser must have all the properties from User AND all the properties from Admin. Therefore, it must have id, name, and permissions properties.

This is a generic constraint. K extends keyof T means that the type K is constrained to be one of the keys of the type T. This ensures type safety by preventing you from trying to access a property that doesn't exist on the obj argument.

TypeScript infers the return type of the getStatus function by analyzing all its return statements. It sees two possible return shapes and combines them into a union type. This is a powerful feature for creating discriminated unions automatically.

The noImplicitAny option is a core part of TypeScript's strict mode. When enabled, it forces developers to be explicit about types. If TypeScript cannot infer a type and it would default to any (e.g., a function parameter without a type annotation), the compiler will report an error, encouraging more robust and self-documenting code.

This scenario requires a tuple type. [string, number] defines an array with a fixed number of elements where the type of each element is known at its specific position. In contrast, (string | number)[] defines an array that can contain any number of strings or numbers in any order.

When a class implements an interface, it must adhere to the contract defined by that interface. The Logger interface specifies a log method that takes a single string argument. The FileLogger class attempts to implement it with a method that takes two arguments (message and level). This mismatch in signatures violates the interface contract, causing a compiler error.

When working with a union type, you can only access properties or methods that are common to all types in the union. Since number does not have a trim method, TypeScript throws an error. To fix this, you would need to use type narrowing (e.g., if (typeof input === 'string') { ... }) to prove to the compiler that input is a string within a specific code block.

When using the generic ApiResponse<T> interface, we specify the type for T as User. This means the data property must be an object that conforms to the User interface, which requires both an id (number) and a username (string). Option A is missing username, Option C doesn't specify the generic type parameter, and Option D provides a string for data instead of a User object.

TypeScript uses control flow analysis to narrow types. The in operator is a type guard. By checking for the existence of the bark property ('bark' in pet), TypeScript understands that inside this if block, the pet variable must be of type Dog, as only the Dog interface in the union has that property. This process is called type narrowing.

Using a union of string literals as a type alias creates a powerful and self-documenting type. It ensures that any variable of type OrderStatus can only be assigned one of the specified string values. This prevents typos and invalid state bugs that could easily occur with a plain string type, and IDEs can provide autocompletion for the allowed values.

The generic constraints T extends object and U extends object require that both arguments passed to the merge function must be of type object. The number 30 is a primitive type, not an object, so it violates the constraint for the generic type U. The other options all pass object-like arguments (note that arrays and even { value: null } are considered objects in JavaScript).

This is a key pattern called 'discriminated unions'. The kind property serves as the discriminant. When TypeScript sees the check case 'circle', it understands that for this code path to be taken, s must be of type Circle. This narrows the union type Shape down to the specific Circle type, making it safe to access the radius property.

When creating an intersection of object types, properties with the same name must have compatible types. Here, property b is string in A and number in B. The intersection of string and number is a type that is impossible to create, which TypeScript represents with the never type. The resulting object type combines all properties, and the intersecting property b becomes never.

TypeScript's design philosophy is to align with JavaScript and the ECMAScript standard. This means any valid JavaScript code is also valid TypeScript code. TypeScript adds its type system on top and often includes features from future ECMAScript proposals (like decorators or optional chaining before they were standard) that can then be transpiled down to older, more widely supported JavaScript versions.

The type () => void is the most precise and safe annotation. It specifically describes a function that takes zero arguments (()) and is not expected to return a meaningful value (void). While Function would work, it is less specific and generally discouraged in favor of more descriptive function types.

Using a generic type parameter <T> is the best approach. The signature unique<T>(arr: T[]): T[] tells TypeScript that the function accepts an array of some type T and will return an array of that very same type T. This preserves the type information of the original array, which is lost when using any[] or unknown[].

The ? syntax in an interface (timeout?: number) marks the property as optional. When a class implements this interface, it is only required to provide implementations for the non-optional properties. Since retries is provided, the class correctly fulfills the contract of the Options interface, and the code compiles successfully.

TypeScript's control flow analysis cannot guarantee that the rest object precisely matches the Omit<T, K> type when using a computed property name for removal in destructuring. The type of rest is inferred as a more general Omit<T, string> or a similar weak type, not the specific Omit<T, K>. This leads to a type mismatch on the return rest; line because the compiler cannot prove that the exact key K was removed.

This question tests control flow analysis and type narrowing. The if condition explicitly checks for state.status being 'success' or 'loading'. Since the function returns within that block, any code executing after it must have a state where status is neither of those. Given the discriminated union State, the only remaining possibility is { status: 'error'; error: Error }. TypeScript correctly narrows the type of state to Error.

Intersecting function types creates a function with multiple call signatures (an overload). The combined type can be called in any way that satisfies at least one of the intersected types. However, when implementing a function of this combined type, the implementation signature must be compatible with all of the intersected signatures. In this case, (a: string, b?: number) => void is a valid implementation because it can handle both calls: one with just a, and one with a and b. The correct answer describes this overload behavior accurately.

An index signature [key: string]: T states that all properties on the object, including explicitly named ones, must have a value of type T. In this case, [key: string]: string requires every property's value to be a string. However, the length property is defined with a value of type number. Since number is not assignable to string, TypeScript reports an error. This ensures the consistency of the type's shape as defined by the index signature.

This demonstrates a key feature of conditional types in TypeScript: they are distributive when the checked type T is a naked type parameter. This means that if you pass a union type to T, the conditional type will be applied to each member of that union individually, and the results will be collected back into a new union. So, IsString<string | number> becomes IsString<string> | IsString<number>, which resolves to true | false, which is simplified to the type boolean.

Function parameter types in TypeScript are contravariant (with strictFunctionTypes: true). This means you can assign a function with a more general parameter type to a variable expecting a function with a more specific parameter type. The logic is that if a function is designed to handle any Animal, it can certainly handle a Dog. So, processAnimal can be safely assigned to processDog. The reverse (processAnimal = processDog;) is unsafe because a function that only knows how to handle a Dog might be called with another Animal (like a Cat), which it cannot process.

The "noEmitOnError": true compiler option prevents TypeScript from generating any JavaScript output (.js, .d.ts, .js.map files) if any diagnostic errors (like type errors) are reported during compilation. The entire emit process is halted. This is a crucial flag for ensuring that you do not ship code with known type-safety issues.

Let's break down the types.
Mapped['name'] resolves to { name: string }.
Mapped['age'] resolves to { age: number }.
The type Result is the intersection of these two types: { name: string } & { age: number }. This intersection describes an object that must simultaneously have a property name of type string and a property age of type number. However, the definition Mapped['name'] describes an object that only has the property name, and Mapped['age'] describes an object that only has the property age. There is no object that can satisfy both of these mutually exclusive structural requirements. Therefore, the intersection of these two types is impossible to instantiate, and TypeScript correctly resolves it to the bottom type, never.

While several options are plausible, the most critical flaw is the check (vehicle as Car).drive !== undefined. This check is unsafe for two main reasons. First, as mentioned in another option, a property could exist and be null. But more importantly, if the property drive doesn't exist on the object at all (like on myBike), accessing it will throw a TypeError at runtime if the object is a proxy or has certain getters. The much safer and correct way to check for the existence of a property on an object is to use the in operator: return 'drive' in vehicle;. This checks for the property on the object and its prototype chain without attempting to access its value, thus avoiding runtime errors. The compiler trusts the vehicle is Car assertion, leading to a runtime crash when myBike.drive() is called.

1. result has type any.
2. The code compiles, and result has type undefined.
3. A compile-time error occurs: "Argument of type '"font"' is not assignable to parameter of type '"theme" | "version"'."
4. A runtime error occurs because the property 'font' does not exist.

Correct Option: 3. This is a better hard question. It forces the user to trace the generic constraints. T is typeof config, K1 is 'settings'. T[K1] is typeof config.settings, which is { theme: string, version: number }. keyof T[K1] is therefore 'theme' | 'version'. The third argument, 'font', is not in this union, so the compiler will throw an error.

Let's re-write the original question to be better. How about variadic tuples? That's definitely hard.

New Question for Generics:
typescript
function tail<T extends any[]>(arr: readonly [any, ...T]): T {
const [_head, ...tail] = arr;
return tail;
}

const myTuple = [1, 'hello', true] as const;
const myTail = tail(myTuple);

What is the type of myTail?

1. (string | boolean)[]
2. ['hello', true]
3. ['hello', true] as const
4. [string, boolean]

Correct answer is [string, boolean]. The as const on myTuple makes its type readonly [1, 'hello', true]. The function signature readonly [any, ...T] matches this. T is inferred as the rest of the tuple, which is ['hello', true]. The implementation return tail returns a new array. TypeScript correctly infers the type of the tail variable inside the function as [string, boolean]. It loses the readonly and literal aspect because the rest operator on arrays creates a new, mutable array. This is a very subtle point. So the type is [string, boolean]. This is a good, hard question.

Let's stick with this one. I will reformat the original question to this new one.

The as const assertion gives myTuple the type readonly [10, 'hello', true]. The tail function's signature readonly [any, ...T] is matched. The generic T captures the "rest" of the tuple type, so T is inferred as ['hello', true]. The function implementation uses array destructuring const [_head, ...rest] = arr;. The ...rest operation creates a new, mutable array from the elements of the readonly tuple. When TypeScript infers the type of this new array, it widens the literal types 'hello' and true to their base types, string and boolean, respectively. Therefore, the returned rest has the type [string, boolean].

This demonstrates a subtle and sometimes surprising behavior in TypeScript's interface extension. When an interface extends another, it can effectively "override" the readonly modifier on a property by re-declaring it without readonly. The type of apiKey on the Config interface is string, not readonly string. Therefore, the assignment config.apiKey = 'new-key' inside the setKey function is type-correct. This behavior allows for creating mutable versions of otherwise readonly interfaces, which can be useful in specific scenarios like object creation.

The key feature here is the asserts condition return type annotation. This is called an assertion signature. It tells TypeScript that if the assert function returns without throwing an error, the condition passed to it must be true. TypeScript's control flow analysis then uses this information to narrow the types in the rest of the function's scope. So, after assert(person), person is narrowed from Person | undefined to Person. After assert(typeof person.name === 'string'), person.name is narrowed from string | undefined to string.

The keyof operator, when applied to a union type, resolves to the intersection of the keys of the types in the union. This is because to safely access a property on a value that could be of type A or B, the property must exist on both A and B. The keys of A are 'a' | 'common'. The keys of B are 'b' | 'common'. The intersection of these two sets of keys is just 'common'. Therefore, 'common' is the only key that can be safely accessed on a variable of type A | B.

TypeScript uses a structural type system. When MyClass is passed to createInstance, its constructor signature is checked against the constraint { new(): T }. While the constructor signature new() matches, the resulting instance type is also considered. Because MyClass has a private property name, its structure is not considered compatible with a generic T that could be instantiated from any constructor returning T. The type system cannot guarantee that the T it promises to return is the specific MyClass type with its private members. To fix this, you would typically use typeof MyClass and work with instance types differently, but as written, the private member breaks the generic structural compatibility.

Revised Question:
You have two files. You want to create a single JS output bundle.js and bundle.d.ts. Your module is set to es2020. Which option is correct?

{
"compilerOptions": {
"target": "es2020",
"module": "es2020",
/ Add settings here /
}
}

With this change, Option C becomes: "outFile": "./dist/bundle.js", "declaration": true and run tsc. This will fail because outFile is not supported for es2020 modules. This is now the correct answer and a much harder question. I will use this revised version.

This question highlights a critical limitation of the TypeScript compiler (tsc). The outFile option, which concatenates multiple input files into a single JavaScript output, is only supported for older module systems: None, System, and AMD. When using modern module systems like es2020, CommonJS, or UMD, each file is treated as its own module and must be emitted separately. Attempting to use outFile with an incompatible module system will result in a compiler error (e.g., error TS6082: Option 'outFile' cannot be specified with option 'module' a value other than 'none', 'system', or 'amd'.).

any is a special escape hatch in TypeScript. When a value is of type any, you can perform any operation on it (like accessing properties, calling it as a function) without a compile-time error. It opts out of the type system. In contrast, unknown is the type-safe counterpart. It is also a top type (any value can be assigned to it), but to perform any operation on an unknown value, you must first prove to the compiler what its type is, either through type narrowing (e.g., if (typeof data2 === 'object' && data2 !== null) ) or by using a type assertion (e.g., (data2 as MyType).property). Line 2 fails because no such narrowing or assertion has been performed.

A structural type system (also known as duck typing) determines type compatibility based on the shape or structure of an object—that is, its properties and their types. It doesn't care about the declared name of the type (User vs. Product). In the example, the printName function expects an object with id: number and name: string. Since the Product instance p has this exact structure, it is considered assignable to the User type, and the call is allowed. In a nominal type system (like Java or C#), types are checked by their explicit names. In such a system, printName(p) would fail because the class name Product is not User, even if they have the same structure.

This question tests understanding of TypeScript's strict control flow analysis. The variable x is declared with the type string | number but is not initialized. The switch statement assigns a value to x only if value is a string or a number. If value is a boolean, control flow proceeds through the switch without x ever being assigned a value. Therefore, when x is accessed at the return statement, its value could be undefined. The compiler detects this possibility and raises an error because undefined is not part of the declared type string | number. The error message might vary slightly (e.g., 'is possibly undefined'), but the core reason is the unassigned path.

This question combines mapped types, conditional types, and generics. The mapped type EventMap iterates over each member of the Route union ('/users' and '/posts'). For each key R, it constructs a value object. Crucially, the generic types Methods<R> and { route: R } are resolved for each specific R in the union.

• When R is '/users', Methods<R> becomes 'GET' | 'POST' and { route: R } becomes { route: '/users' }.
• When R is '/posts', Methods<R> becomes 'GET' and { route: R } becomes { route: '/posts' }.
  The correct answer shows the fully resolved type where each property corresponds to a correctly specialized object structure.