Concepts in TypeScript & Web APIs, page 6
Modern Bundlers & TypeScript: Transpile, Don't Check
Modern bundlers like Vite prioritize speed by only transpiling TypeScript files, not type-checking them. This enables sub-50ms updates during development. The footgun: your dev server won't report type errors; you must run tsc --noEmit separately.
Speed Up Builds with TypeScript Project References
Treat your codebase like a set of independent packages. Project References let you split a large project into smaller, interconnected pieces, dramatically speeding up builds by only recompiling what's changed.
TypeScript's `declare`: A Promise to the Compiler
declare promises the TypeScript compiler a value exists, even if it can't see the source. This lets you use untyped JavaScript libraries or browser APIs without errors.
TypeScript: Type-Only Imports and Exports
Use import type to tell the compiler an import is only for type-checking and should be erased from the final JavaScript. This prevents tools like Babel from generating unwanted runtime code when compiling files in isolation.
Triple-Slash Directives: Compiler Hints in Comments
Triple-slash directives are compiler instructions inside comments, telling TypeScript about file dependencies. They're mostly seen in older projects or for global types, as modern import statements are preferred.
Module Augmentation: Adding Types to External Libraries
Module augmentation is like monkey-patching for types, letting you add definitions to external modules. Use it to add a user property to Express's Request object.
export = : TypeScript's CommonJS Export Syntax
Think of export = as TypeScript's version of module.exports. It replaces a module's entire export with a single value, like a class or function. It's used for compatibility with CommonJS modules. The footgun is mixing it with standard exports.
Shipping TypeScript Types in package.json
The types field in package.json tells TypeScript where to find your package's type definitions. Use it when publishing a library to enable autocompletion for users. The footgun is putting type dependencies in devDependencies instead of dependencies.
Identifying JS Library Structure for TypeScript Types
To type a JS library, first identify its structure: module, global, or UMD. This dictates your .d.ts file's shape. You'll check docs for import/require or <script> usage. The footgun is misidentifying a UMD library, leading to incorrect import types.
TypeScript Namespaces: The Original Module System
TypeScript namespaces bundle related code under a single global name, preventing name collisions. They are useful for older projects or UMD library types, but the footgun is using them in modern apps; prefer standard ES modules.
Understanding this in TypeScript
In TypeScript, this is determined by how a function is called, not where it is defined; arrow functions capture the enclosing this lexically, and TypeScript adds optional this parameters to type-check the expected context at compile time.
ES Modules in TypeScript: The Compile-Time Contract
TypeScript ES modules are a compile-time target, not a runtime guarantee. Configure this when targeting modern browsers or Node with native ESM. The footgun is omitting .js extensions in imports, which it requires in ESM output even for .ts source files.
Ambient Module Declarations: Compile-Time Trust Falls
Ambient module declarations are compile-time trust falls: you tell TypeScript the shape of code it cannot see. Use them for untyped npm packages, CSS imports, or CDN scripts.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles