-
-
Notifications
You must be signed in to change notification settings - Fork 6.4k
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
Pass config to commonjs and make optimizeDep more flexible #1460
Comments
The premise of Vite is that you should use packages that provides native ESM formats as much as possible. By allowing you to configure and use all the packages that ship fundamentally broken code for browsers, we will never move the ecosystem forward. It's not Vite's goal to be compatible with every package out there. Some notes on your use cases:
Since you already found workarounds, this will be wontfix. |
No the commonjs plugin assumes all dependencies are commonjs if no options pass to it.
Last but not least, we could not expect commonjs work without hack in every other package, the 2 issues of rollup rollup/plugins#743, rollup/plugins#658 occurs when import every complex package. (even more rollup/plugins#658 is also a workaround that not work in every case). Some notes in my cases:
So please. |
I'm always frustrated when import a library, I almost have to optimize every single dependency when I try to import them in my code. The dist of dependencies could be packaged by any tools (webpack, tsc, ...), we cannot expect the default config of commonjs would resolve all issues.
vite/packages/vite/src/node/optimizer/index.ts
Lines 192 to 195 in 6d279d3
Describe the solution you'd like
I'd like to have more control on single deps (direct or indirect)
I know the resolve/node-resolve would find the dist file of package for me, but I would still like to
default
export.config.optimizedDeps.commonjs
to rollup.Vite keeps these information and translate them to commonjs plugin.
Describe alternatives you've considered
I checked again and again for rollup plugins used in optimizing pass, the only hack/workaround I could use is
customResolver
inaliasPlugin
.Additional context
And use the plugin in alias (workaround)
The solution I hope goes like
The text was updated successfully, but these errors were encountered: