In an effort to make config a bit closer to what people generally think Babel already does, this makes Babel's config-level options merge. That means everything passed in programmatically, and loaded via a .babelrc or a referenced .extends block. Plugins from a config will not merge with plugins inside of a preset itself, since names and values of plugins inside presets are essentially private implementation defined data.

This means

{
  presets: [
    ['env', {modules: false}],
  ],
  env: {
    node: {
      presets: [
        ['env', {}],
      ]
    },
  },
}

for example would use {modules: false} by default, but use {} as the options when the env has been set to node for instance. I've also made it so that passing false as the options value for a preset or plugin will disable that item entirely.

I should also mention that things merge based on the identity of the plugin function itself. That means that

presets: [
  '@babel/preset-env',
  require('@babel/preset-env').default,
]

would throw an error for the user about duplicates, and if one was in an env or extends-file, they would merge happily. It seemed like the safest way to ensure that someone didn't refactor and break their config or something.

Importantly the feature that is no longer possible with this is using the same plugin twice. To allow for that, this PR includes logic to allow users to name specific plugins to uniquely identify them by expanding the 2-tuple to an optional 3-tuple, as

plugins: [
  ['module-resolver', {from: 'view', to: './view' }, "resolve-view"],
  ['module-resolver', {from: 'model', to: './model' }, "resolve-model"],
]

which would then not override eachother since they have different names.

Not super pretty, but also probably not super common so potentially not a real issue. Definitely curious for thoughts on that one.

Breaking Changes

Plugin/preset evaluation ordering

The obvious breaking change is obviously that things won't be duplicated anymore, but the potentially less obvious point is that things potentially change order. That said, I think the order is better this way. The merging happens up front for both plugins and presets, so where before each nested config was essentially merged into the plugin list in order, now they merge first then execute. So for example

presets: [
  'pre',
],
plugins: [
  'plug',
],
env: {
  thing: {
    presets: [
      'pre-env',
    ],
    plugins: [
      'plug-env',
    ],
  }
}

before would have been

• process pre
• process plug
• process pre-env
• process plug-env

in essentially increasing order, but now they merge first, so it'll be

• process pre
• process pre-env
• process plug
• process plug-env

which to me is what people expect more anyway, but it is what caused most the the unittest changes that you'll see with this PR.

The priority of a given config object goes in increasing order of

• values from .extends files, recursively applying the rules here for files
• the values at the root of the
• the values from a .env block

and values passed in via the programmatic options will merge with a higher priority, overriding values from config files.

Preset options

Presets can provide options the same way config files can, but it isn't something that is done super often. That said, it complicates merging because for instance it isn't obvious what priority the preset config values would have compared to the user's config files. This PR officially changes the semantics of preset options to be default values, so user config will automatically override any default value that a preset has specified.