isolatedModules & verbatimModuleSyntax

## The problem this syntax solves TypeScript's central rule is that types are erased: the compiler emits JavaScript with the type layer removed. That creates an awkward case for imports. `import { User } from './models'` is ordinary JavaScript syntax that, at runtime, actually loads `./models` and binds one of its exports. But if `User` is an interface, there is no runtime export named `User` at all — the interface emitted nothing. Keeping that import in the output would produce a module that fails to link. TypeScript's historical answer is **import elision**: while emitting, the compiler looks at how each imported name is used and drops the ones that are only ever used in type positions, dropping the whole statement when nothing is left. Elision is convenient but implicit, and its correctness depends on information from other files. ## What the explicit form does ```ts import type { User } from "./models"; ``` This declares up front that the statement is type-only. Two guarantees follow. **It is always erased.** The emitted JavaScript contains no trace of the statement, so the module is never loaded because of it. If `./models` had a top-level side effect you were relying on, a type-only import will not run it — you would need a separate `import "./models";`. **The binding is a type, not a value.** Everything below is legal, because each use is a type position: ```ts let current: User; function save(u: User): Promise<void> { /* ... */ } interface Session { user: User } ``` And this is a compile error, because it uses the name where a runtime value is required: ```ts const u = new User(); // error: 'User' cannot be used as a value console.log(User); // error ``` That second guarantee is why the form is useful even for classes. A class produces *both* a type and a runtime value; importing it with `import type` deliberately takes only the type half, and the compiler will stop you the moment someone reaches for the value half. ## The inline modifier When one module gives you both types and values, you do not need two statements: ```ts import { type User, createUser } from "./models"; ``` `createUser` is a real value import and survives into the output; `type User` is dropped. There is a matching export form: ```ts export type { User }; export { type User, createUser } from "./models"; ``` ## Why interviewers care Elision requires the compiler to know what every imported name *is*, which requires reading the other file. Tools that compile one file at a time — esbuild, swc, Babel's TypeScript transform — never read the other file. They see `import { User } from './models'` and have no way to tell an interface from a function, so they must keep the import. If `User` was type-only, the emitted module now imports something that does not exist. Explicit `import type` removes the guesswork: the `type` keyword is *syntax*, visible in the single file being transpiled, so any tool can delete it correctly without cross-file knowledge. That is why compiler options exist to require it, and why modern codebases write it by hand rather than relying on elision. ## Practical guidance - Reach for `import type` (or the inline `type` modifier) whenever an import is genuinely type-only. It costs nothing and documents intent. - Do not use it for a module you import *for* its side effect; use a bare `import "./setup";` for that. - Remember the direction of the guarantee: `import type` guarantees erasure, whereas a plain import only *might* be erased. When in doubt, being explicit is always the safe side. - The same reasoning applies to exports: re-exporting a type through a plain `export { ... } from` is the mirror-image hazard, and `export type { ... } from` is the mirror-image fix.