fix(resolve): don't let a user resolve.extensions override shadow framework-internal entries - #3226
Open
AhmedElBanna80 wants to merge 1 commit into
Conversation
…mework-internal entries A webpack `resolve.extensions` / Turbopack `resolveExtensions` override replaces vinext's resolver defaults (`normalizeViteResolveExtensions` returned only the user's list). The same resolver also resolves vinext's own internal, extensionless entry `nitro/dist/presets/bun/runtime/bun` — a `.mjs` file — so a user list that omits `.mjs` makes that entry unresolvable and the build dies with `[UNRESOLVED_ENTRY] nitro/dist/presets/bun/runtime/bun`. Append a small set of framework-required extensions (`.mjs`/`.js`/`.mts`/`.cjs`/`.cts`) at the LOWEST precedence after the user's list. User extensions keep highest precedence for their app code; the internal entries stay resolvable. This mirrors what `buildViteResolveExtensions` already does for the default path. Fixes the `app-dir/resolve-extensions` case from the Next.js e2e suite. Test: tests/file-matcher.test.ts — a user override omitting `.mjs` still yields `.mjs`/`.js` (at lowest precedence), and an already-listed internal extension is not duplicated.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
A webpack
resolve.extensions/ TurbopackresolveExtensionsoverride replaces vinext's resolver defaults —normalizeViteResolveExtensionsreturned only the user's list. But the same resolver also resolves vinext's own internal, extensionless entrynitro/dist/presets/bun/runtime/bun(a.mjsfile), so a user list that omits.mjsmakes that entry unresolvable and the build dies with:Reproduced by the official Next.js e2e fixture
test/e2e/app-dir/resolve-extensions.Fix
Append a small set of framework-required extensions (
.mjs/.js/.mts/.cjs/.cts) at the lowest precedence, after the user's list. User extensions keep highest precedence for their own app code; the framework-internal entries stay resolvable. This mirrors whatbuildViteResolveExtensionsalready does for the default path (appending.cjs/.cts).packages/vinext/src/routing/file-matcher.ts— one function,normalizeViteResolveExtensions.Test
tests/file-matcher.test.ts:.mjsstill yields.mjs/.js, at lowest precedence (user extensions retain index 0);Mutation-proved: removing the append loop reds the first test. Existing
resolve-extensionsbehaviour is unchanged — the current e2e fixture prepends a custom extension with the defaults already present, so appending is a no-op there; only the "user dropped.mjs" case changes, which is the bug.