-
Notifications
You must be signed in to change notification settings - Fork 414
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
fix: smarter handling of user's babel plugins & presets #613
base: master
Are you sure you want to change the base?
fix: smarter handling of user's babel plugins & presets #613
Conversation
I believe the test failure is spurious; it seems to be timing-related and I can't reproduce it locally. |
I published this branch as https://www.npmjs.com/package/@jitl/linaria for testing purposes. |
Thanks for tackling this one @justjake . I'm surprised the only reply yet has been from a bot because I've been stuck on this #612 too. Sourcing your build library, I got a different error: console output
Here's my Babel presets config: [
'@babel/preset-env',
{
modules: false,
loose: true,
useBuiltIns: 'usage',
corejs: 3,
},
],
'@babel/preset-typescript',
'@babel/preset-react',
'@jitl/linaria/babel', |
Motivation
Users should have as much control as possible about the plugins in Linaria's babel pipeline.
Current issues:
shaker
always specifies thepreset-env
preset, which can lead to babel duplicate plugin issues if the user also specifiedpreset-env
.Summary
Instead of blindly unshifting PluginItem specifiers to babel's
plugins
andpresets
arrays, instead check for the presence of the plugin, and if present, merge existing user-specified plugin options and the options that Linaria requires..Options are merged like
{ ...userPluginOptions, ...linariaPluginOptions }
, to always prefer the linaria options in case of conflict.Test plan
I created a reproduction for #612, seen here: https://github.com/justjake/linaria-babel-options-issue-repro
linaria
at from this branch. Runyarn build
inlinaria
action = extractor
-> build now succeeds!action = shaker
-> build now succeeds!I should also test the new version of Linaria with example integrations in the community, such as the nextjs-linaria example.
This is somewhere between a bug-fix and a new feature. The change has the potential to break existing configs in subtle ways, if user options start being respected. So, maybe consider for inclusion in 2.0.0?