Babel configs are ignored

[rschristian]

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 or babel.config.js file ...optimize-plugin only uses your babel configuration when generating modern bundles.

However, both configFile and babelrc are set to false:

optimize-plugin/src/worker.js

Lines 59 to 61 in aefb895

	const modern = await babel.transformAsync(source, {
	configFile: false,
	babelrc: false,

This should stop any config files from being loaded, AFAIK. Am I misunderstanding something, or are the docs outdated perhaps?

[dineshtrivedi]

I am having the same experience, my .babelrc is being ignored.
Have you found a solution for it @rschristian ?

[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.

[dineshtrivedi]

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.

[rschristian]

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.

[dineshtrivedi]

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]

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?

[developit]

@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]

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.