In a TypeScript project, `import styles from './Button.module.css'` fails with "Cannot find module './Button.module.css' or its corresponding type declarations." How do you make the compiler accept that import, and does your fix change anything at runtime?

## What the error is actually saying The message "Cannot find module ... or its corresponding type declarations" is a *type* error, not a file-not-found error. The compiler resolved the specifier as a module and found no type information describing what that module exports. TypeScript ships type knowledge for JavaScript and for declaration files; it has no built-in notion of CSS, SVG, or any other non-code asset. Turning `./Button.module.css` into something importable is a build-tool job, and describing its shape to the checker is your job. ## Wildcard ambient module declarations An *ambient* declaration describes something that exists without defining it. An ambient **module** declaration names a module specifier and describes its exports: ```ts // src/types/assets.d.ts declare module '*.module.css' { const classes: { readonly [key: string]: string }; export default classes; } declare module '*.svg' { const url: string; export default url; } ``` The name may contain a single `*` wildcard, and any import specifier matching the pattern picks up those types. When two patterns both match a specifier, the more specific pattern is the one used, so you can declare `'*.module.css'` separately from a broader `'*.css'`. ## Condition one: the file must be a script, not a module TypeScript classifies every file by a single rule: a file with a top-level `import` or `export` is a **module**; a file with neither is a **script**, and its declarations land in the global scope. Inside a script, `declare module 'x' { ... }` *declares* an ambient module. Inside a module, the identical syntax means something different — it *augments* an existing module — and augmenting a module that does not resolve is an error. So adding one innocent `import type { Foo } from './foo'` at the top of your `assets.d.ts` breaks every wildcard declaration in it. If you need an imported type, use an inline import type instead, which does not make the file a module: ```ts declare module '*.module.css' { const classes: import('./css-types').ClassMap; export default classes; } ``` ## Condition two: the file must be in the program No source file ever imports a `.d.ts`, so the only way it enters compilation is by being matched by `files` or `include` in `tsconfig.json`. A very common failure is putting the declarations in a `types/` directory that the include globs do not cover: the editor may pick it up through a different config while `tsc` in CI does not, producing the classic "works locally, fails in the build" report. When a declaration seems ignored, first confirm the file is in the program at all. ## Nothing changes at runtime This is the point interviewers are usually probing. `declare module` emits no JavaScript whatsoever — like every part of the type layer, it is erased. The emitted code still contains an import of a `.css` file, and something has to make that import mean something: a bundler with a CSS-modules loader, or a runtime that understands the extension. If you compile with `tsc` and run the output in Node, the import throws, and the declaration will not have warned you. The declaration is a *promise* about a shape you arranged elsewhere; the compiler trusts it without verification. ## Shaping the declaration honestly `{ [key: string]: string }` is convenient but permissive: `styles.buton` type-checks and is `string`, so a typo survives to runtime as `undefined`. Two ways to tighten it: enable `noUncheckedIndexedAccess`, which makes every index access `string | undefined` and forces you to handle the miss; or generate a precise per-file declaration (`Button.module.css.d.ts` listing the real class names) with a typed-CSS-modules tool, at the cost of a generation step in the build. ## Related cases Image and font imports follow the same pattern with `const url: string`. JSON is the exception: instead of declaring `'*.json'` yourself, turn on the `resolveJsonModule` compiler option, which makes the compiler read the JSON file and infer its exact type — a far better result than a hand-written wildcard.