TS2307 - Show the path(s) where TypeScript tried to search for a file

[phistuck]

Suggestion

🔍 Search Terms

module resolution, helpful error, helpful errors, 2307, paths

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Show the path(s) where TypeScript tried to search for a file to aid getting to the right path

📃 Motivating Example

import { wow } from '../../../a';
Error -
Cannot find module '../../../a' or its corresponding type declarations.ts(2307)
With this suggestion implemented, it will show -

Cannot find module '../../../a' or its corresponding type declarations.ts(2307)
Tried -
/users/PhistucK/projects/trial/src/a
/users/PhistucK/projects/trial/polka/polka/polka/a

Could also show the searched file extensions, might be verbose but sometimes helpful -

/users/PhistucK/projects/trial/src/a.ts
/users/PhistucK/projects/trial/src/a.tsx
/users/PhistucK/projects/trial/src/a.js
/users/PhistucK/projects/trial/src/a.jsx
/users/PhistucK/projects/trial/src/a.mjs
/users/PhistucK/projects/trial/polka/polka/polka/a.ts
/users/PhistucK/projects/trial/polka/polka/polka/a.tsx
/users/PhistucK/projects/trial/polka/polka/polka/a.js
/users/PhistucK/projects/trial/polka/polka/polka/a.jsx
/users/PhistucK/projects/trial/polka/polka/polka/a.mjs

💻 Use Cases

Sometimes IntelliSense/your editor/your brain does not know what exactly is wrong (another ../? an extraneous ../?) because it is not so apparent what is the resulting path. Showing the paths that TypeScript searched in that did not have that file would go a long way in aiding the user with getting to the right path.
I find myself a lot of times with such a vague error message that is not helpful and it is a trial and error, adding one more ../, removing it, looking at the path of the file and re-calculating the number of ../ and so on.
../ is not the only problem, though, it is just an example.
Ideally, the user input and the path-completion would be shown in two different colors in order to show where the user is wrong (maybe it was not the ../, maybe it was a case sensitivity issue, a dash or whatever, maybe even both of them), or where the search paths are incorrect (a user error, but not necessarily an error in that specific import path).

Obviously, since ../ will not actually show up in the resulting path, it is fine (and necessary) not to artificially add it to the resulting path just for showing the original user input in the resulting path.

The context is that I see this error within Visual Studio Code, not sure whether other places where this error is emitted show this information or not...

[MartinJohns]

This sounds really verbose for the default output. What's wrong with using --traceResolution?

[phistuck]

Not familiar with it. I tried to add it under compilerOptions in tsconfig.json, reloaded the TypeScript server with verbose logging enabled, looked at its log, look at all of the different logs under "Output" and could not find the relevant output anywhere.

Besides, the output of that flag (according to the documentation) is way too verbose. I think the first version I mentioned, without the file extensions, is sufficiently helpful and not verbose. In case the file extensions are deemed helpful, you can always just mention them as a list once, so something like -

Cannot find module '../../../a' or its corresponding type declarations.ts(2307)
Tried (file extensions precedence - .ts, .tsx, .js, .jsx, .mjs) -
/users/PhistucK/projects/trial/src/a
/users/PhistucK/projects/trial/polka/polka/polka/a

I guess in the case of ../, though, it will only try a single path, right? Maybe that case deserves a special consideration.

[RyanCavanaugh]

--traceResolution is the intended solution here. In many project configurations the probe list is very large and would be unfriendly to flood the console with those.

[phistuck]

Like I wrote, I did not get it to show up anywhere when using Visual Studio Code

But I was mainly thinking about the error shown in Visual Studio Code itself. Is there anything that can be done there?

[boliveira]

Hello!

Yes the issue is getting to know which paths tsserver used to search for modules when using Visual Studio Code. We are unable to get those logs from tsserver. Is there anything we can do to know which paths tsserver is checking when we open a typescript file in Visual Studio Code?

[typescript-bot]

This issue has been marked as "Declined" and has seen no recent activity. It has been automatically closed for house-keeping purposes.