[v2] Convert babel config loading to same patterns as rest of site with "onCreateBabelConfig" node api & actions setBabelPlugin and setBabelPreset

[KyleAMathews]

@jquense – is there a strong argument for the current behavior? It's surprising when all the defaults presets/plugins disappear.

I think people should be able to extend the default config but not mutate or replace it. Gatsby breaks w/o some of our babel settings.

[KyleAMathews]

Going to work on this shortly.

I'll add two new actions — setBabelPreset and setBabelPlugin. Instead of the current API in v1 where you directly mutate the babel config, you'll add new babel plugins like the following:

setBabelPlugin({
  resolve:  require.resolve(`babel-plugin-emotion`),
  options: {
    sourceMap: true,
  },
})

I'll be changing the API for plugins from the non-standard modifyBabelrc to onCreateBabelConfig.

I'll also pass the same stage names to onCreateBabelConfig as are used in the webpack config.

Also changing the current unexpected behavior that adding a .babelrc file to your site overwrites the default babelrc settings. The new behavior will be to parse that and merge its settings in instead of replacing.

I'll also be adding a replaceBabelConfig action — similar to the new replaceWebpackConfig — if you want complete control over the config.

[jquense]

I went with the current behavior for a few reasons.

• The v1 behavior had a bunch of magically local plugin resolution that didn't seem to make sense given the other v2 changes
• There aren't really any babel specific things that are required for gatsby (yes?) since we already ship compiled the browser code provided by gatsby
• its MUCH harder to remove stuff from a config via an api vs adding it (like webpack). things like add-module-exports can unexpectedly break code, and its not easy to remove without regexing a path in the config
• babel 7 will fail much harder if a config is wrong, like a plugin added twice, or a bad setting.
• related to the last point, its a bit odd that a fully specified babelrc in a site directory is actually merged with a hidden one. That behavior is very unbabel-like, which doesn't merge config at different levels.

That said, i don't think the current behavior is complete or right, it was mostly a clean simple starting point, I'm sorry i haven't gotten any updates sent on that front, just short on time, but i've started it a few times :P

[KyleAMathews]

its a bit odd that a fully specified babelrc in a site directory is actually merged with a hidden one. That behavior is very unbabel-like, which doesn't merge config at different levels.

Yeah... you're right. Changed my mind on this :-) I'll make a "Customizing Babelrc" docs page as part of my PR that'll include a sample .babelrc file that replicates the default core behavior that they can copy into their site as a starting point.

[KyleAMathews]

Fixed in #4298