Replies: 2 comments
-
I've just ran into this issue as a consumer of a package. It's set up correctly (according to the documentation) and very similar to yours. However, it doesn't work until the ESM file has an |
Beta Was this translation helpful? Give feedback.
0 replies
-
I opened a pull request to correct the docs (#7714), it was rejected as this will be fixed in Vite v3 by #6827. |
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
-
I have recently migrated both my frontend and my Node.js backend to native ES modules. As part of this migration, I have run into trouble with several libraries that do not publish ES modules or that do not publish them properly, and I am in the process of opening pull requests and adapting my own libraries to improve this.
I have come across the Library section in the Vite docs. With the
lib
option, Vite provides a way to create both an UMD and a ESM bundle. The documentation recommends to publish the package with the followingpackage.json
:This looks exactly like the problem that I'm seeing in various libraries. Node.js interprets all
.js
files as CommonJS (unless"type": "module"
is set inpackage.json
), so the ES bundle is interpreted as CommonJS, causing an error that theexport
keyword is not defined. I believe that the ES bundle should have the.mjs
extension. Even better, the UMD bundle should have the.cjs
extension, to make sure that it also works in modules that have"type": "module"
set, but I could imagine that that can cause problems for frontend libraries.I think that this problem can easily be solved by changing the
fileName
function to ``fileName: (format) => `my-lib.${format}.${format === 'es' ? 'mjs' : 'js'}```. I am wondering whether I am misunderstanding something, or whether I should open an issue to correct the documentation, or whether this has already been discussed anywhere?Beta Was this translation helpful? Give feedback.
All reactions