Replies: 1 comment
-
|
Moving issue to a discussion. Everyone has to follow the same rules. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
master)dataToEsmis a standalone utility, no bundling involvedExpected Behavior
When
dataToEsmis called withincludeArbitraryNames: trueon data that has akey named
default, it should produce valid JavaScript. SincedataToEsmalwaysemits a trailing
export default {...}, thedefaultkey can only be exposedthrough that default export object — it must not also be emitted as a named
export.
Actual Behavior
dataToEsmemitsexport { _arbitrary0 as "default" }in addition to thetrailing
export default {...}. Both forms declare the module's default export,so the generated code is invalid:
Generated output for the reproduction below:
Additional Information
Reproduction (pure function — runs in Node, no bundler required):
A
defaultkey falls into theincludeArbitraryNamesbranch and is emitted asexport { _x as "default" }. But both the string formexport { x as "default" }and the identifier form
export { x as default }create the module's defaultexport, which conflicts with the
export default {...}thatdataToEsmalwaysappends.
This surfaced while working on Vite's CSS-modules named exports
(vitejs/vite#22393): a
.default {}class name compiledfor a modern target produces broken output.
A fix (skip a
defaultkey from named exports, keeping it object-only) with atest is ready and will be opened as a PR referencing this issue.
Beta Was this translation helpful? Give feedback.
All reactions