discussion: plugin options revamp

[DanielSchaffer]

The flurry of activity on this project over the last couple weeks has made me realize that the current options structure isn't terribly forgiving with regards to providing the kind of flexibility that is required in customizing options for Babel. As part of the 3.0.0 release, I'd like to change the format of the options to make this a little more straightforward and manageable. Here are the goals for this change:

• allow complete "pass-through" of settings for babel-loader and presets
• allow separate definitions of above for global/shared and per-target settings
• properly merge default, shared, and per-target settings (currently there is a weird combination of manual object construction and Object.assign)
• ensure that settings for Babel and settings specific to the plugin are clearly separated

Fortunately, I don't think this requires a huge number of breaking changes. Here are my proposed changes:

• options.babel.loaderOptions will be added to provide shared/global babel-loader options
• BREAKING: plugins and cacheDirectory will be removed from the options.babel object in favor of using the corresponding properties in options.babel.loaderOptions
• options.babel.presetOptions will remain as a shortcut to customize @babel/preset-env, and the modules key will continue to be forced to false
• options.targets[key].babel will be added to provide babel-loader options on a per-target basis
• options.targets[key].browsers will remain as a shortcut to customizing the @babel/preset-env's targets.browsers option
• Babel preset and plugin ordering: Since ordering of both presets and plugins matters, wherever presets and plugins are defined, the most specific array will be used. This means that a target-specific configuration could remove plugins or presets defined as defaults or at the global level. Options defined for presets will be merged by preset name (so for example, options for @babel/preset-env at the global level will be merged with those set in the presets array at the target level, regardless of the order of the respective presets arrays.
• Upcoming breaking changes will be deprecated in v2.1.0, and console warnings will be added to notify users on usage

@rangermeier, @platosha, @daKmoR, @web-padawan, @adamdoyle, @LarsDenBakker - I'd love to hear your input on this.

[LarsDenBakker]

I think these changes make a lot of sense, being able to customize options and plugins per target would be very beneficial.

[web-padawan]

I have submitted a proposal to integrate your plugin to Storybook: storybooks/storybook#5531

This could be a good chance to discuss use cases of the Storybook core, relevant code is here: https://github.com/storybooks/storybook/tree/next/lib/core/src/server

[LarsDenBakker]

Will you have time to implement (some) of this customization?

I can work on implementing this if we settle on an API.

[DanielSchaffer]

@LarsDenBakker Sorry, I've been busy with some other projects, and I'm not sure when I'd be able to get to this one myself. I can write up a feature issue with AC if you'd like to take a swing at implementing.

[DanielSchaffer]

@LarsDenBakker sorry for the long delay! I'm starting to look at getting some of these changes done. Are there still things you'd like to discuss?

[LarsDenBakker]

We switched to recommending rollup, where it is a lot easier to implement these kinds.of things.

[DanielSchaffer]

Interesting! Thanks for getting back to me!

[semoal]

I just saw this issue, hmm, probably we can go on a feat version, with the changes i've made. We could work on parallel on this changes with a @next /@canary / @alpha version, as you want.