Repository navigation
Babel configs are ignored #27
Description
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
.babelrcorbabel.config.jsfile ...optimize-plugin only uses your babel configuration when generating modern bundles.
However, both configFile and babelrc are set to false:
Lines 59 to 61 in aefb895
This should stop any config files from being loaded, AFAIK. Am I misunderstanding something, or are the docs outdated perhaps?
Activity
dineshtrivedi commentedon Apr 8, 2022
I am having the same experience, my
.babelrcis being ignored.Have you found a solution for it @rschristian ?
rschristian commentedon Apr 8, 2022
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.
dineshtrivedi commentedon Apr 20, 2022
Thank you for your response @rschristian
I understand what you mean. Would be possible to share your
webpack.configwith me, please? It would be extremely helpful to understand how you solved this.rschristian commentedon Apr 20, 2022
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-envis only ran in dev, asoptimize-pluginhere picks that up for prod.dineshtrivedi commentedon Apr 21, 2022
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.
rschristian commentedon Apr 21, 2022
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 removingbabel-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 tooptimzeworked, 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?
developit commentedon Apr 25, 2022
@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.
rschristian commentedon Apr 25, 2022
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.