Repository navigation
"Cannot find module" message should be more explicit, saying where it's looking #5149
Description
With all the vagaries around module loading, it'd be great to give a more verbose, helpful error message for "Cannot find module 'foo'", saying where the compiler looked for the module. That can help clue the user into (1) how TypeScript works and (2) how to fix their issue.
The message text could be semi-static, maybe something like: IF using commonjs loading AND path isn't relative THEN say "Couldn't find module Foo; searched node_modules directory off directory XXXX and its ancestors and the package.json Typings path YYYY.
Better doc around the module loading algorithm helps, but just putting some of that info in the error message makes it very easily discovered. It also helps clue the user into what isn't the problem (e.g. the message above confirms that using commonjs module loading & found Typings in package.json, but something else seems to be the problem).
Activity
mhegazy commentedon Oct 21, 2015
Would love to see a proposal/PR here. one constraint is it needs to work with the language service as well as with the compiler. the failed lookup locations are cached on the file in case of the compiler but not the language service. either ways any help would be appreciated.
BretJohnson commentedon Oct 21, 2015
Could someone maybe document here, or point to existing doc elsewhere, on the rules for where it looks (at least in the commonjs case). That could be a good first step in turning those rules into a reasonably concise message. I can help with the 2nd part, but less so with the 1st. Thx.
mhegazy commentedon Oct 21, 2015
The module resolvers will return a list of
ResolvedModuleWithFailedLookupLocationsobjects, each has a file path and a set of locations where lookup failed, here is the definition: https://github.com/Microsoft/TypeScript/blob/master/src/compiler/types.ts#L2327Here is the resolver for node modules, you can see how the failed lookup locations are populated: https://github.com/Microsoft/TypeScript/blob/master/src/compiler/program.ts#L50
The error is actually reported later on in the checker when the resolution of the module fails: https://github.com/Microsoft/TypeScript/blob/master/src/compiler/checker.ts#L1013
Vladimir Matveev (@vladima) can advice on the best way to tackle the the language service part
DanielRosenwasser commentedon Oct 21, 2015
We should consider a
--verboseResolutionoption here.mhegazy commentedon Oct 23, 2015
We talked about with before. +1 for that
BretJohnson commentedon Oct 24, 2015
The module loading rules should also be documented (in precise English) in the TypeScript wiki/handbook, right? And we don't really have that doc currently, correct? Can someone on the TypeScript team fill that in. Thanks.
mhegazy commentedon Oct 28, 2015
That is correct. we need to add some more documentation on resolving references and imports. i logged an issue a while back: microsoft/TypeScript-Handbook#68
PRs for documentation, partial be it, are definitely appreciate it.
Vladimir Matveev (@vladima) or myself can answer any specific questions you would have about how resolution work.
BretJohnson commentedon Mar 22, 2016
FWIW, I'd still love to see this doc & feature. Have the module loading rules been documented yet?
vladima commentedon Mar 22, 2016
With nightly builds you can use
traceModuleResolutionoption to enable verbose logging of module resolution process.mhegazy commentedon Mar 22, 2016
I have added some documentation to the handbook about module resolution: https://github.com/Microsoft/TypeScript-Handbook/blob/release-2.0/pages/Module%20Resolution.md.
Check it out, and let me know if there is gaps that you would like to see filled.
1241282015 commentedon Feb 21, 2017
I think you can write xx.d.ts file, within that you can write declare clause, and use reference in your xx.ts file. And you can read: http://www.typescriptlang.org/docs/handbook/modules.html#ambient-modules