docs: Use .mjs extension for library ESM bundle #7714
Closed
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.
As explained in #7609, when importing an ES module in Node.js, either its package needs to have
"type": "module"
set in itspackage.json
, or its file extension needs to be.mjs
. Otherwise the file will be interpreted as CommonJS and the import will fail.The Library section of the Vite docs documents how to publish a library and also recommends to add an
exports
section topackage.json
. As far as I am aware, this section tells Node.js which file to import, although I believe some frontend bundlers are also adding support for it these days. The current documentation encourages developers to publish their ESM bundles with a.es.js
extension, which will make the package impossible to be imported from an ESM Node.js project. Since not many Node.js projects use ESM yet, many developers are not aware of this problem.This pull request changes the documentation to recommend the use of the
.mjs
extension for the generated bundle. This way the library bundle can be successfully used both in Node.js and in frontend bundlers.What is the purpose of this pull request?