fix(rollup): keep import attributes in the build output - #4519
Conversation
|
@agantelin 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: Pro Plus 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 |
f3d2df3 to
a17e494
Compare
|
Pushed an update (force-push, same two source lines): added a test that an explicit |
commit: |
🔗 Linked issue
#4518
❓ Type of change
📚 Description
Two defaults in
getRollupConfig, both still overridable by user config:output.importAttributesKey: "with". Rollup 4 re-prints the import attributes of externalmodules with its default key,
assert, which Node.js removed in 22.0.0 (esm: drop support for import assertions nodejs/node#52104).Rollup flips this itself in v5 ([v5.0] Use "with" as the keyword of import attributes by default rollup/rollup#6248, merged to
rollup-5) and documents the optionas the workaround until then. It goes in the
defudefaults, sorollupConfig.outputstill wins.Nothing on the supported matrix loses: the runtimes that take
assertbut rejectwithare allbelow
engines.node.supported: { "import-attributes": true }on the esbuild plugin. esbuild silently drops importattributes for every
esXXXXtarget (checked up toes2025) and the target here ises2019, soattributes written in
.ts/.jsnever reach Rollup at all. Merged with the user's ownesbuild.options.supportedrather than spread past it, so setting an unrelated feature flagdoesn't quietly drop this one.
Without these, a module that marks a JSON import external produces code no supported runtime can
load, while the build stays green: pages render and only the affected route answers 500.
@nuxt/icon'sserverBundle.externalizeIconsJsonis the case I hit — it generates a correctwith { type: "json" }import and has no way to know it will be rewritten.📝 Checklist
es2019target norimportAttributesKeyis documented today; this changes no documented behaviour.Verification
test/unit/import-attributes.test.tscovers three things, each checked by breaking thecorresponding line one at a time: the emitted attribute key, an explicit
rollupConfig.outputsetting surviving the merge, and a
.tssource keeping its attributes through the esbuildtransform.
pnpm vitest run test/unit,tsc --noEmit, eslint andprettier -care green.A
test/fixture/regression route wouldn't be portable — the case needs an external JSON import,which the worker and edge presets can't load at all — so the regression is pinned at the config
level instead. Happy to move it if you'd rather have it elsewhere.
End-to-end, including the runtime 500 before and 200 after:
https://github.com/agantelin/nitro-import-attributes-repro (cases 2 and 3)