🔍 Search Terms

Module resolution, ESM, ES modules, Browser, avoid resolution heuristics.

✅ 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 isn't a request to add a new utility type:https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals:https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

TLDR: Provide a simple resolution mode thatresolves only relative paths and absolute paths explicitly mapped in the tsconfigpaths attribute, everyhing else should result in an error, to be used for Browser ESM-based projects.

This is a follow-up to the discussion at#62206 (comment) where theresolutionMode='classic' deprecation is discussed.

There is currently no appropriattemoduleResolution mode offered for TypeScript projects that:

1. Target the Browser as the running environment (meaning not NodeJS)AND
2. Use ES modules (ESM)AND
3. Don't use bundling, instead deploy the transpiled ES modules directly.

NodeNext andBundler are both NodeJS-centric resolution modes, which perform a bunch of NodeJS heuristics to resolve any non-relative paths (for example auto-discoveringnode_modules folders andpackage.json files by walking up the folder hierarchy). Moreover, per 'Bundler' mode docs, it resolves import URLs that aren't valid URL in a Browser context (for example when omitting the.js file extension).

The proposedBrowser mode should follow as closely as possible the logic used by the Browser to resolve modules at runtime, where it resolves relative/absolute paths, orbare paths specified inImport Maps.

None of the existing resolution modes are appropriate for projects that meet criteria 1-3 listed above. (For reference the Chromium codebase has lot of such TS projects in it, more contexthere). This seems like a significant gap in TypeScript compiler's offerings since Browser ESM-based projects are very common, at least enough to justify having an appropriate resolution mode, instead of trying to accomodate such projects withBundler orNodeNext, which seems more of a workaround than a proper solution.

Whileclassic mode was also a bit odd (since it also attempted several heuristics when trying to resolve absolute paths), it kind of worked for this type of projects, and with its deprecation the gap described above is more prominent.

📃 Motivating Example

Implementing this feature would close a gap in TypeScript'smoduleResolution oferrings which are currently heavily NodeJS-centric, somewhat under-representing the amount of code that is written for a Browser as the runtime environment where all the resolution heuristics of NodeJS don't apply.

💻 Use Cases

1. What do you want to use this for?
   Browser, ESM, non-bundled web projects.

2. What shortcomings exist with current approaches?
   NodeNext andBundler are not appropriate for projects targeting the Browser as the runtime environment and don't use any bundling.

3. What workarounds are you using in the meantime?
   Still usingClassic mode, while investigating alternatives, seehttps://issues.chromium.org/issues/423789047 for more context, where we are trying to unblock migrating the Chromium codebase from updating to the upcoming TypeScirpt v6 and v7 versions. Might also look for possibly implementing a custom resolution mode using the programmatic compiler API fromhttps://github.com/microsoft/TypeScript/wiki/Using-the-Compiler-API#customizing-module-resolution, depending on how the effort to unblock Chromium's migration to v6,v7 goes.