Suggestion

🔍 Search Terms

List of keywords you searched for before creating this issue: I've tried resolveModuleName, typeRoot, api and their combinations.

✅ Viability Checklist

• 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

At the Compiler API Wiki, You can see that resolveModuleNames suggested implementation treats node modules packages typings and custom typings differently (here).

This means anyone that uses the ts.resolveModuleName API has to implement the fallback and search on moduleSearchLocations (which I assume, we'll get those by reading the tsconfig and scanning for the typeRoot.

I am not sure whether this is a bug or not, but I would assume ts.resolveModuleName would respect the typeRoots given in the passed compiler options. What do you think? Is there a reason it doesn't behave this way?

NOTE: I've not just relied on the example, I've tested it myself.

💻 Use Cases

Any tool that uses the compiler API will need this, for example, I'm writing an ESLint plugin that makes sure every dependency either comes with type declarations or it has the corresponding @types package installed next to it. (It's here)

Thanks!