Open benlesh opened 8 years ago
There's already --traceResolution
to show which files are being searched for.
I'm not sure how we'd determine that --module commonjs
is the right thing to suggest when a file isn't found?
Happy to PR "Cannot find module '{0}'. If you're trying to import from node_modules you probably want '--moduleResolution node'"
if that's deemed acceptable.
A more complex version that checks "would this work if they had indeed used moduleResolution=node" would be ideal, but looking at the source IMO it would be needless complex considering a generic description like above is prolly satisfactory.
It's really not great for us to just guess at what the problem might be. There are at least a dozen reasons why module resolution might fail, and any one of the other module resolution settings might be the correct one.
It's really not great for us to just guess at what the problem might be.
You'll do a LOT better at guessing what the problem might be than I will. I had to ask a dozen people and then file an issue before I had someone tell me what I was doing wrong. The compiler error expected me to just "know".
I think it's important to recognize when it comes to the user experience here that all of your error messages are a cue to being troubleshooting. This is one of the primary purposes of a compiler, after all, to identify problems (and, ideally, help the developer solve them). It would be ideal if you provided the users with some help to that effect.
Microsoft has always had really solid sets of guidelines when it comes to error messages. I don't think they don't apply here just because it's a CLI tool. There's user experience to think about.
There are at least a dozen reasons why module resolution might fail
These guidelines from Microsoft suggest listing out possible causes in order of likelihood if a cause can't be determined. Barring that, why not at least add a link to a URL with possible steps to take.
I believe what @blesh is suggesting is that if the compiler can't give you recommendations directly, TS should consider having web docs that lists all known errors w/ their error codes and then explains the error in depth and offers common solutions, e.g. using --moduleResolution node
; when someone googles "Cannot find module 2307" ideally the first result would be a page on typescriptlang.org that has this info. Microsoft has been really good about this, so we just would like to see something similar here cause it's very helpful. 😄
The main issue is that when the resolution is done, it does not know if it is an error to not find the module, as the module could be an ambient module declaration (i.e. declare module "foo" { .. }
). but when we are sure it is an error, later on in the checker, resolution has long been over and we do not have the context. so it is mainly an implementation/language semantics issue.
@mhegazy totes, we realize that now; there are quite a few reasons it could be failing. We're now suggesting better documentation :trollface:
We can definitely update the documentation. the current documentation is at http://www.typescriptlang.org/docs/handbook/module-resolution.html, which has the error code in it, but we can also add a SO question with the link to help users find the docs.
@mhegazy wow totally missed that doc page. It doesn't come up on the first page of google, so not sure what (if anything) you could do to help the docs have a better SEO rank. The SO question with a link would hopefully help, as you described. Thank you.
Related to our woes with #8189, if the compilation errors gave some better hinting when it was unable to resolve a module, we might not have taken so long to find the solution (and we wouldn't have filed an issue!).
The idea would be that if there is a compilation error of
cannot file module "whatever"
, to make some intelligent checks against the parameters the compilation is running under and suggest using--moduleResolution node
if the user is not already doing so.