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

Personne n'a encore pris cette issue.

### 🔍 Search Terms

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

### ✅ Viability Checklist

- [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
- [x] This wouldn't change the runtime behavior of existing JavaScript code
- [x] This could be implemented without emitting different JS based on the types of the expressions
- [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
- [x] This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
- [x] 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](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules#importing_modules_as_bare_names) specified in [Import Maps](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script/type/importmap).

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](https://issues.chromium.org/issues/423789047#comment5)). 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.

Commencez par examiner les modes moduleResolution existants et les recommandations de l’API du compilateur TypeScript concernant la résolution de modules personnalisée. Comparez le comportement de NodeNext, Bundler et Classic aux règles demandées pour la résolution des chemins relatifs, absolus et tsconfig. Le travail est considéré comme terminé lorsqu’un mode Browser pris en charge couvre le cas d’utilisation ESM dans le navigateur décrit, sans bundling ni heuristiques de résolution de Node.js.

Rédigé par le modèle d'indexation à partir du texte de l'issue.