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
Omit plugin-proposal-dynamic-import when using preset-env running @babel/cli #10194
Comments
Hey @AdamRamberg! We really appreciate you taking the time to report an issue. The collaborators If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack |
Doesn't |
@nicolo-ribaudo Nope doesn't work. First of all it throws when it normalizes the options because it checks against this list of plugins, which doesn't contain Now when I come back to it, it might be a better solution to just make it possible to exclude |
Yes, I'd consider it a bug that it isn't possible to exclude |
Alright! Makes sense that excluding the syntax plugin isn't desirable. Haven't been contributing to Babel before, but would like to take a stab at it and create a PR for making it possible to exclude |
Thanks! I'm assigning this issue to you, but don't feel pressured 😛 |
I run into the exact same problem where the new version breaks our build and also tried to exclude and it didn't work 😢 |
As a workaround, use |
@nicolo-ribaudo is this something that I can pick up? |
@vivek12345 the issue has been resolved in #10218, which has been approved by @JLHwung, but has not been merged to master yet. Not sure if something else is needed to get it merged though. |
Alright. I actually missed the PR part. Didn't notice it has a PR already. Thanks for pointing that out. |
Feature Request
Is your feature request related to a problem? Please describe.
The problem I'm having started after #10109 was released.
I want to use preset-env to transform static ES modules, but not dynamic imports. Dynamic imports should be left untouched. My case is that I'm building shared components / packages that should be transformed before distributed. However, in the consuming applications using the shared packages above I want Webpack to use the dynamic imports for code splitting. I guess that I could omit transforming our shared packages and then transform them in the consuming packages, however I would like to be able to support certain browsers / environments "out of the box" in the the shared packages.
Describe the solution you'd like
Make it possible to send in
caller
options to the CLI (supportsDynamicImport and supportsStaticESM). Currently thecaller
option is getting overridden by the CLI, see this. Callername
should still always be overriden by the CLI. Can't think of any drawbacks supporting this behavior.Describe alternatives you've considered
Another solution would be to support excluding
plugin-proposal-dynamic-import
via thepreset-env
config. This however seems a little redundant, since we already havesupportsDynamicImport
.Teachability, Documentation, Adoption, Migration Strategy
Usage from command line
babel --caller '{supportsDynamicImport: false}'
Usage in code
The text was updated successfully, but these errors were encountered: