-
-
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
Struggling to polyfill dynamic import manually after upgrading to v2.3.0 #3388
Comments
Why won't the legacy plugin work? Are you seeing issues on Edge 18 with the legacy plugin or do you prefer the regular build for some reason?
The legacy plugin should convert ESM modules to SystemJS modules, so it should not need the |
@ludofischer because the legacy plugin is providing the SystemJS runtime only for browser that are not supporting ESM (ie: browsers that are going to run <script nomodule> tags) |
if I could handle this with the legacy plugin with SystemJS, I'd be happy ! |
If for instance I would be able to prevent modern chunks distribution and just distribute the legacy chunks like without being wrapped in <script nomodule> it could work (via a option in legacy plugin, like |
Ouch! You're right. The problem is that even bringing back the polyfill won't solve this, we would need to downgrade esbuild. The original problem that led to removing the polyfill was upgrading esbuild. We found if you use dynamic import, esbuild 0.11+ and rollup together (which Vite all combines under the hood) and the esbuild browser target includes |
hum yeah, that's a shame because to me that sounds like a esbuild bug. I understand the fix they did but it should only apply to a node environment... see https://esbuild.github.io/getting-started/#bundling-for-node. Otherwise it does not make any sense. Wouldn't it be easier to submit a PR to esbuild here and bring back the built-in polyfill ? |
I wonder whether you couldn't remove the modern bundle already via a custom plugin and the transformIndexHtml hook.
I suspect it is going to be faster to solve the issue at the Vite level. Even if someone makes a PR to esbuild, the maintainer needs to accept it, then merge it, esbuild needs to make a new release, Vite needs to bump esbuild and make a new release too, etc. And looking at the esbuild commit log, nobody regularly working on Vite ever had a commit merged into esbuild. |
Yes, probably can be worked-around for sure, while we figure out a better solution. |
To be honest, I have only made one commit to Vite, so it's not like I am very representative of the main maintainers. From what you've told me about your situation, I would try to use https://vitejs.dev/guide/backend-integration.html and generate my own HTML without the modern bundle. If you use https://vitejs.dev/guide/api-plugin.html#transformindexhtml to remove the modern bundle, it looks like you receive the existing HTML as a string, so in that case the only way forward is some search/replace on that string, which could be brittle. |
Thanks for this discussion and sorry for the disruption with this use case in v2.3.0. @AlexandreBonaventure please check out #3434, released as part of Vite v2.3.3. You should be able to set in your vite.config.js |
@patak-js Awesome! thanks for reacting so quickly, it works gangbusters! |
@patak-js following up, and as an fyi: There is still a general issue that makes supporting edge18 in particularly difficult because of #3388 (comment) Meaning that now since you guys restored the dynamic polyfill we can use it BUT, all the other polyfills/es syntax won't be transpiled (still because the legacy plugin target non ESM browsers). What I've been using Of course, I could build a custom config/plugin for vite to do that, but that's a lot of work for reinventing the wheel |
Describe the bug
The latest minor release 2.3.0 dropped the built-in support for dynamic import polyfill. That's a shame for us bc we're developing an app with MSFT WebView 1 which uses Edge 18 under the hood. This browser falls in the category of support ESM but not dynamic import, so using the legacy plugin won't work.
We have to polyfill it ourselves now which is totally fine (we did that previously when using [email protected]) but if you follow the guide here: https://github.com/antfu/vite-dynamic-import-polyfill-example you can see that it is using a renderDynamicImport rewrite technique which was discarded (here: e6f7fba#diff-e650901c71d775f0adc67ad233a9738d5322a3a5ad58155d709c77270dd32ff2L46) in the built-in plugin because it messes with the import analysis plugin. see https://github.com/vitejs/vite/pull/2976/files#diff-121079017d1fa98d6a0ea3354d5c73df45ab277078228cd7384c7a4e84c5a813L229
It means the migration path it not as easy as advertised bc of this issue, now that the polyfill is not built-in there is no way for us to hook into the build analysis plugin. So, we experience all sort of issues with css not loading and dynamic import relative path not being taken into account. (see antfu/vite-dynamic-import-polyfill-example#1 as well)
Reproduction
No reproduction for now, I'd like to gauge the stance of the team regarding this issue before committing too much time. I can provide if necessary. I wonder why this polyfill is not supported in the legacy plugin. As a user, if you need to target Edge 15 (no ESM support) you expect Edge 18 to work without a doubt, but here it won't work right ? (or am I missing something?)
Before submitting the issue, please make sure you do the following
The text was updated successfully, but these errors were encountered: