-
-
Notifications
You must be signed in to change notification settings - Fork 6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add an option for .mjs file output for browser-based projects #7963
Comments
Hi, |
This is achievable by this config: import { defineConfig } from 'vite';
export default defineConfig({
build: {
rollupOptions: {
output: {
entryFileNames: `[name].[hash].mjs`,
chunkFileNames: `[name].[hash].mjs`,
},
},
},
}); https://stackblitz.com/edit/vitejs-vite-qnjtmn?file=vite.config.js&terminal=dev |
Yep, that was what I was talking about in the first sentence. I think this would be useful as a top-level option since it's an official Node.js convention, and Node.js is used for most builds for browser-based environments. Curious of your thoughts. |
Modifying |
Clear and concise description of the problem
I've been using a custom Rollup config to workaround not being able to output
.mjs
files for my native ES modules for a frontend, browser-based project until now, so I'm curious if can this be exposed for Vite browser-based projects too (<script type="module">
)? I'm happy to see this is being added for library mode in #6827, so I think it would be useful in a browser-based case too.I prefer it for clarity purposes and it allows for easier use in isomorphic projects (Node.js and in the browser), but there is apparently the downside of MIME type support by legacy web servers (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules#aside_%E2%80%94_.mjs_versus_.js). I'd love this to be the default behavior, but it may be a bad choice to do so for those unaware of potential broken rendering due to a missing MIME type for
.mjs
files. Then again, the popularity of this project could push the ecosystem to evolve to support it; I'm open to either. What are your thoughts? I'm sure I'm not alone in this.And of course thank you for making such a great tool. 😀
Suggested solution
An option
esModuleFileExtension
that defaults to.js
but can be overridden to anything (e.g..mjs
). I think this would provide maximum flexibility for the ecosystem (e.g. perhaps someone sets up a custom pipeline that wants TypeScript output, they could use.mts
).Alternative
If a boolean option flag is preferred,
isEsModuleFileExtensionMjs
Additional context
No response
Validations
The text was updated successfully, but these errors were encountered: