Sample questions
Typescript Tooling ConfigDifficulty 1
What is the primary purpose of a tsconfig.json file in a TypeScript project?
- aIt lists the npm packages the project depends on
- bIt configures how the TypeScript compiler type-checks and compiles the project✓
- cIt stores the runtime environment variables for the app
- dIt defines the routes for a web server
Explanation:tsconfig.json tells tsc (or any tool driving it, like a bundler) which files to include, which compiler options to apply (target, module system, strictness flags), and where to emit output. It has nothing to do with npm dependencies (that's package.json), runtime env vars, or server routing.
Typescript Tooling ConfigDifficulty 1
Setting "strict": true in tsconfig.json does what?
- aMakes the compiled JavaScript run faster at runtime
- bOnly affects code formatting, not type checking
- cEnables a bundle of stricter type-checking rules (like
noImplicitAny and strictNullChecks) at once✓ - dPrevents the project from being compiled unless there are zero comments in the code
Explanation:strict is a shorthand flag that turns on a whole family of stricter checks together (noImplicitAny, strictNullChecks, strictFunctionTypes, and others). It's a compile-time type-checking setting — it has no effect on the runtime speed of the emitted JS, code formatting, or comments.
Typescript Tooling ConfigDifficulty 2
function greet(name) {
return "Hello, " + name;
}
With
"noImplicitAny": true in
tsconfig.json, what happens when this file is compiled?
- aIt compiles successfully because TypeScript infers
name is a string - bIt compiles successfully because function parameters are always
any by default, even under noImplicitAny - cIt throws a runtime
TypeError when greet is called without an argument - dIt fails to compile with an error✓
Explanation:TypeScript cannot infer a parameter's type just from how it's used inside the function body — with no annotation and no usable context (like a default value or a typed call site being checked), name would fall back to any. noImplicitAny turns that fallback into a compile error instead of silently allowing it.
Typescript Tooling ConfigDifficulty 2
let age: number = 30;
age = "thirty";
Assuming this is compiled with
tsc, what happens?
- a
tsc reports a compile-time type error; if you then run the emitted JS anyway, age would just hold the string at runtime✓ - b
tsc refuses to emit any JavaScript at all under any configuration, so nothing can ever run - cIt compiles cleanly, because TypeScript automatically converts
"thirty" to the number 30 - dIt throws a runtime error the moment
age = "thirty" executes
Explanation:TypeScript's type checking is a compile-time-only concern — tsc will flag the reassignment (string isn't assignable to number) as an error, but by default it still emits JavaScript output (unless noEmitOnError is set). Since types don't exist at runtime, the emitted JS just does a plain assignment with no crash and no auto-conversion.
Typescript Tooling ConfigDifficulty 1
What does running tsc --noEmit do?
- aDeletes all previously compiled
.js output files - bType-checks the project and reports errors, without writing any
.js output files✓ - cCompiles the project to JavaScript but strips out all comments
- dRuns the project's unit tests instead of compiling
Explanation:--noEmit tells tsc to do its normal type-checking pass and report any errors, but skip the file-writing step entirely. This is commonly used as a standalone type-check step in CI, separate from whatever actually bundles/transpiles the code (e.g. Babel, esbuild, Vite).
Typescript Tooling ConfigDifficulty 1
A team uses both tsc and ESLint (with @typescript-eslint) on the same codebase. What's the typical division of responsibility?
- aESLint replaces
tsc entirely — once ESLint is configured, tsc is no longer needed - b
tsc checks code style (indentation, quote style) while ESLint checks types - c
tsc checks type correctness while ESLint checks code-quality/style rules✓ - dThey do the exact same job, so teams normally only run one or the other, never both
Explanation:tsc is the actual TypeScript type checker — it's the authority on whether your types are consistent. ESLint (with the @typescript-eslint parser/plugin) handles code-quality and style concerns (unused variables, preferring const, no-floating-promises, etc.), and some of its rules use the type information tsc computes, but ESLint doesn't replace type checking itself.