fix(rollup): load handler meta staged under file:// URLs - #4630
nikolas-sapa wants to merge 2 commits into
Conversation
`lookupNodeModuleSubpath()` reports the package root export as `"./"`, and `join()` keeps the trailing slash, so the guessed specifier became `"pkg/"`. Specifiers ending in `/` are a deprecated exports pattern: resolving one emits DEP0155 and always returns undefined. Strip the trailing slash so the root export is looked up as `"pkg"`. The guess is still only used when it resolves back to the same file, so this cannot introduce an incorrect external.
The `?meta` specifier is resolved by the host bundler before the handlers-meta plugin's `resolveId` runs, and bundlers report absolute paths as `file://` URLs when the file lives outside the project root (e.g. server routes in Nuxt layers). The virtual id built from the resolved id was loaded with `readFile` directly, which does not understand URL strings and failed with ENOENT even though the file exists. Renaming the file to `.ts` worked only because the layer's vite resolver then returned a plain path. Convert `file://` ids back to paths before reading. Fixes nitrojs#4564
|
@nikolas-sapa is attempting to deploy a commit to the Nitro Team on Vercel. A member of the Team first needs to authorize it. |
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
🔗 Linked issue
Fixes #4564
❓ Type of change
📚 Description
When a Nuxt layer contains
.jsserver routes, nitro scans and registers them but then fails to load them via thenitro-handler-metavirtual module:The chain:
#nitro-internal-virtual/server-handlers-metageneratesimport ...Meta from "<handler>?meta"for every scanned handler.resolveIdasks the host bundler to resolve the<handler>specifier. For files outside the project root (which is the normal case for server routes in Nuxt layers), the bundler reports the resolved id as afile://URL.\0nitro-handler-meta:file://...and later loads it withreadFile("file://...")— butfs.readFiledoes not understand URL strings, so it throws ENOENT even though the file exists.Renaming the file to
.tsmade the error disappear only because the layer's resolver then returned a plain path; the file format itself was never the problem. It also explains the issue's second workaround: with a layer folder sharing a prefix with the base layer, the bundler's resolver caches/normalizes differently and stops returning the URL form.This converts
file://ids back to paths withfileURLToPathbefore reading, mirroring what the externals plugin already does (src/rollup/plugins/externals.ts:41).📝 Checklist
$prefix (not applicable — bug fix with linked issue).