In TypeScript, when you write `import _ from 'lodash'`, where does the compiler look for that package's type declarations, and what does the error "Could not find a declaration file for module 'lodash'" mean?

## Two lookups behind one import An import specifier goes through module resolution: the compiler turns the string `'lodash'` into a location on disk, walking `node_modules` folders the way the configured `moduleResolution` mode prescribes. That step answers "which package is this?". A second, separate step answers "what describes this package's types?". Beginners tend to fuse the two and conclude that TypeScript reads a library's JavaScript to work out its shape. It does not — not for a dependency in `node_modules`. It reads *declaration files* (`.d.ts`), which are type-only files containing signatures and no implementations. ## Where a package advertises its own declarations A package that is written in TypeScript, or that ships hand-written declarations, points at them itself. The oldest mechanism is a field in its package.json: ```json { "name": "my-lib", "main": "./dist/index.js", "types": "./dist/index.d.ts" } ``` `types` and `typings` are synonyms; `types` is the current spelling. There is also a filename convention: if `main` points at `./dist/index.js` and a `./dist/index.d.ts` sits beside it, the compiler picks it up even with no field at all. Modern packages that publish an `exports` map advertise declarations through a `types` condition inside it instead. That form is only visible to the resolution modes that read `exports` at all — `node16`, `nodenext` and `bundler`. The legacy `node10` mode ignores `exports` entirely, which is a common reason a perfectly well-typed dependency looks untyped. A package that ships its own declarations needs nothing installed alongside it. Most libraries written this decade are in this category, and installing an `@types/...` package for them is usually wrong. ## The @types fallback When the package itself declares nothing, the compiler looks for `node_modules/@types/<name>`. Those are the DefinitelyTyped packages: community-written declarations published under the `@types` scope for libraries whose authors did not ship any. `lodash` is the canonical example — it is plain JavaScript, so its types live in `@types/lodash`. Scoped packages get a name-mangled folder: declarations for `@scope/pkg` live in `@types/scope__pkg` (the slash becomes a double underscore). These are development-time dependencies. They belong in `devDependencies`, they are never loaded at runtime, and they can drift out of step with the library version they describe — a real source of wrong-but-compiling code. ## What the error is actually telling you > Could not find a declaration file for module 'lodash'. '.../lodash/lodash.js' implicitly has an 'any' type. Try `npm i --save-dev @types/lodash` … Read it as: *both* lookups failed, so the whole module is `any`. The error appears only because implicit `any` is disallowed — it is reported under `noImplicitAny`, which `strict` turns on. Turn `noImplicitAny` off and the diagnostic disappears, but nothing improves: every symbol from that import is still `any`, so the checker will happily accept a misspelled method and every other misuse. Silencing the message is not fixing the problem. A related but different message is `Cannot find module 'x' or its corresponding type declarations.` That one means the *specifier itself* did not resolve — the package is not installed, or the resolution mode cannot see the subpath you asked for. ## How you fix it In order of preference: check whether the library already ships types under a newer version; install the `@types` package the error names; or, if neither exists, provide a local declaration for it — a different topic, but the point is that the declaration has to come from somewhere the compiler looks. If the package *does* ship a `.d.ts` and you still get the error, suspect the resolution mode rather than the package. ## None of this reaches runtime Declaration files are erased. Adding `@types/lodash` changes what the checker knows and changes nothing about the emitted JavaScript: the same `require('lodash')` or `import` is produced either way, byte for byte. That is why `@types` packages sit in `devDependencies` and why a missing one is a developer-experience failure, never a production failure — the code that was going to run still runs, just unchecked.