optimize-plugin
optimize-plugin copied to clipboard
Babel configs are ignored
In the ReadMe, there's the following line:
In order to migrate to optimize-plugin, you'll need to move your babel configuration into a
.babelrc
orbabel.config.js
file ...optimize-plugin only uses your babel configuration when generating modern bundles.
However, both configFile
and babelrc
are set to false
:
https://github.com/developit/optimize-plugin/blob/aefb895750e217be250230f9c0cb78afc00aa4fe/src/worker.js#L59-L61
This should stop any config files from being loaded, AFAIK. Am I misunderstanding something, or are the docs outdated perhaps?
I am having the same experience, my .babelrc
is being ignored.
Have you found a solution for it @rschristian ?
No solution beyond running Babel separately and before this plugin, no.
I think that's fine and correct for my use case though, so it's not a problem.
Thank you for your response @rschristian
I understand what you mean. Would be possible to share your webpack.config
with me, please? It would be extremely helpful to understand how you solved this.
Sorry, this isn't a simple use case.
I have added this for preact-cli
, which is a Webpack-based build tool. It's got a fair bit going on in it, but the gist of it is that we use the following Babel config in both dev & prod: https://github.com/preactjs/preact-cli/blob/af9ebd0a9347cbcc36c234981ee9ed212df49990/packages/cli/lib/lib/babel-config.js
@babel/preset-env
is only ran in dev, as optimize-plugin
here picks that up for prod.
Amazing, @rschristian Thank you. I have done something similar to you, but you gave me other ideas. I will spend more time on it someday in the coming month.
Thank you again, I really appreciate it.
No problem.
Preact-CLI always have a need for babel-loader
, as a) we need something to handle the dev environment and b) we need to handle JSX, TS, decorators, and any other non-standard syntax. That setup "works" for us, though it might not be optimal or how this tool was intended to be used. Not really sure at the moment!
@developit An extra question: given the prevalence of syntax like JSX, TS, decorators, etc., should optimize-plugin
's docs be recommending removing babel-loader
? As far as I can tell, most users using Webpack are using some non-standard syntax, so the instruction to remove the loader doesn't really make sense to me. Even if passing a babel config to optimze
worked, Webpack is going to error out far earlier if there's JSX, TS, or any number of other non-standard syntax.
I just don't see that instruction actually being valid for most users, unless I'm missing something?
@rschristian I think they could be clearer about this, yes. The docs should say "using a simpler or faster loader to handle non-JS syntax, like Sucrase". The idea isn't necessarily to avoid the need for a loader at all, it's that the loader shouldn't be doing any ES version-related trabspilation.
Gotcha, good to confirm; I didn't imagine the intent was to run this first to handle those transforms (assuming the babel config was customizable) but the docs pointed that way.