fix: smarter handling of user's babel plugins & presets #613
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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?