Provide a new, simple 'browser' moduleResolution mode for Browser, ESM-based, non-bundled projects.

🔍 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 that resolves only relative paths and absolute paths explicitly mapped in the tsconfig paths 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 https://github.com/microsoft/TypeScript/issues/62206#issuecomment-3657546540 where the resolutionMode='classic' deprecation is discussed.

There is currently no appropriatte moduleResolution 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 and Bundler are both NodeJS-centric resolution modes, which perform a bunch of NodeJS heuristics to resolve any non-relative paths (for example auto-discovering node_modules folders and package.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 proposed Browser mode should follow as closely as possible the logic used by the Browser to resolve modules at runtime, where it resolves relative/absolute paths, or bare paths specified in Import 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 context here). 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 with Bundler or NodeNext, which seems more of a workaround than a proper solution.

While classic 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's moduleResolution 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 and Bundler 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 using Classic mode, while investigating alternatives, see https://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 from https://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.

Inizia esaminando le modalità moduleResolution esistenti e le indicazioni dell'API del compilatore TypeScript per la risoluzione personalizzata dei moduli. Confronta il comportamento di NodeNext, Bundler e Classic con le regole richieste per la risoluzione dei percorsi relativi, assoluti e tsconfig. Il lavoro è completato quando una modalità Browser supportata gestisce il caso d'uso descritto di ESM nel browser senza bundling e senza euristiche di risoluzione di Node.js.