[btea]

close #23860
refs #14967, #18103

[sapphi-red]

This PR might also fix #18914

[koriyoshi2041]

Validated this at 6288bda22ab6. The HMR playground passes 130 tests with 1 skipped, including the new first-request <link> case. Applying only the regression fixture to current main@a976df388 fails at the expected boundary (red remains red after editing dep-load.js), so the test distinguishes the fix rather than just covering the steady state.

I also checked the earlier ensure-before-load/revert pair (#12774/#12929). That regression depended on eagerly calling ensureWatchedFile for the resolved request; this change only creates the module-graph entry early, while filesystem watching still occurs after a successful read. I did not find a remaining correctness issue in this diff.

[sapphi-red]

Maybe we should use canSkipImportAnalysis(id) for the second argument. But this bug (?) exist before this PR, so let's check it seprately.

[sapphi-red]

I've added a failing test. I think we need to fix this

[koriyoshi2041]

The rollback added at c7d7322 can remove a pre-existing shared module, not only the node created by this request. removeModuleOnLoadFailure is derived from the raw URL lookup before resolution, but _ensureEntryFromUrl may resolve that new URL to an existing idToModuleMap entry used by another URL. If load then fails, _removeModule deletes the shared id/file entry (and only mod.url from urlToModuleMap), leaving aliases pointing at a detached node. Please have _ensureEntryFromUrl report whether it created the node, or compare the resolved node against the pre-existing id mapping before making rollback destructive. A regression with two URLs resolving to one id, where the second URL load fails, should preserve the first URL module.

[sapphi-red]

I've added a new failing test.

[koriyoshi2041]

The changed head addresses the shared-node rollback case I raised. removeModuleOnLoadFailure is now false when the resolved id already exists, and _removeModule independently retains a node once another URL, an importer, or a completed transform is attached. The new overlapping-load regression exercises the timing-sensitive alias path directly, and the hosted Node 20/22/24/26 plus macOS/Windows matrix is green. I don't see a remaining issue at 60c71b65.

[sapphi-red]

I've pushed a different fix as the code had some bugs:

1. Assume that /foo resolves to /foo.js, but loading that file fails. The previous code had already registered the module. Its cleanup sees /foo.js differs from the requested /foo, assumes another request needs the entry, and keeps it. Then, if you replace foo.js with foo.ts and retry /foo, Vite reuses the cached /foo.js resolution and fails again, although resolving /foo should find foo.ts.
2. Assume two requests overlap:
   1. Request A: creates module node M, starts loading, pauses
   2. File changes: invalidates M, allowing a fresh request
   3. Request B: reuses M, starts loading successfully
   4. Request A: fails and removes M from the graph
   5. Request B: continues transforming with M, now detached
   6. Request B’s import analysis can then fail because its importer is missing from the graph, producing ERR_OUTDATED_OPTIMIZED_DEP, even though B loaded successfully.