"Cannot find module" message should be more explicit, saying where it's looking

[BretJohnson]

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).

[mhegazy]

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]

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]

The module resolvers will return a list of ResolvedModuleWithFailedLookupLocations objects, 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#L2327

Here 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

@vladima can advice on the best way to tackle the the language service part

[DanielRosenwasser]

We should consider a --verboseResolution option here.

[mhegazy]

We talked about with before. +1 for that

[BretJohnson]

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]

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.

@vladima or myself can answer any specific questions you would have about how resolution work.

[BretJohnson]

FWIW, I'd still love to see this doc & feature. Have the module loading rules been documented yet?

[vladima]

With nightly builds you can use traceModuleResolution option to enable verbose logging of module resolution process.

[mhegazy]

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.