Skip to content
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

Babel config includes more plugins than it should #1665

Closed
jquense opened this issue Jul 31, 2017 · 2 comments
Closed

Babel config includes more plugins than it should #1665

jquense opened this issue Jul 31, 2017 · 2 comments

Comments

@jquense
Copy link
Contributor

jquense commented Jul 31, 2017

Just noting this for posterity. https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/utils/babel-config.js#L149-L160

Babel preset env will try and only load plugins that are needed, but it's defeated in more modern envs by the stage-0 preset. Here's what happens:

  • Things like async/await make it to stage 4 during the babel v6 lifespan, so they can't be removed from the stage-3/stage-4 presets without a breaking change.
  • Each stage preset includes all the others above it, so stage-0 includes 1-4
  • Chrome doesn't need the async function plugin, according to the env preset, but the stage-0 preset includes it so its included regardless.
@KyleAMathews KyleAMathews mentioned this issue Aug 8, 2017
@davidhouweling
Copy link

davidhouweling commented Sep 25, 2017

@KyleAMathews This is probably related... I want to tweak the default env configuration so that it has useBuiltIns: true. This is because babel will not automatically include es6 features such as Array.prototype.includes as it expects it to be there in the environment (without it, loading the site in IE9 results an error in IE9 about includes not being defined). Settings useBuiltIns to true means it will also include the polyfill within the bundle.

So my initial idea was to add a exports.modifyWebpackConfig to my project's gatsby-node.js file... Firstly, I wanted to see what was presently in the config, so I did the following:

exports.modifyWebpackConfig = ({ config, stage }) => {
  if (stage === 'build-javascript') {
    config.loader('js', (current) => {
      console.log(JSON.stringify(current, null, 2));
      return current;
    });
  }
  return config;
};

And the output was...

{
  "test": {},
  "exclude": {},
  "loader": "babel",
  "query": {
    "presets": [
      "C:\\git\\project\\node_modules\\babel-preset-env\\lib\\index.js",
      "C:\\git\\project\\node_modules\\babel-preset-stage-3\\lib\\index.js",
      "C:\\git\\project\\node_modules\\babel-preset-react\\lib\\index.js",
      [
        "C:\\git\\project\\node_modules\\babel-preset-env\\lib\\index.js",
        {
          "loose": true,
          "uglify": true,
          "modules": "commonjs",
          "targets": {
            "browsers": [
              "> 1%",
              "last 2 versions",
              "IE >= 9"
            ]
          },
          "exclude": [
            "transform-regenerator",
            "transform-es2015-typeof-symbol"
          ]
        }
      ],
      "C:\\git\\project\\node_modules\\babel-preset-stage-0\\lib\\index.js",
      "C:\\git\\project\\node_modules\\babel-preset-react\\lib\\index.js"
    ],
    "plugins": [
      "C:\\git\\project\\node_modules\\gatsby\\dist\\utils\\babel-plugin-extract-graphql.js",
      "C:\\git\\projects\\node_modules\\babel-plugin-add-module-exports\\lib\\index.js",
      "C:\\git\\project\\node_modules\\babel-plugin-transform-object-assign\\lib\\index.js"
    ],
    "cacheDirectory": true
  }
}

This looks strange... then I realised, it is because i have a project level .babelrc file. So it is loading them up first, then gatsby is adding it's own configurations as well. As a result, we have duplications? I'm not sure what the knock on effect of this is to babel. Does it apply the plugin again for both env, and react (as in duplicating the work load?). I think there needs to be an easier/cleaner way to do this without having the duplication, but also preserving the order we need (i.e. react should probably always be last, env should be first, and the different preset-stage* should be between them, etc.).

Thoughts?

@jquense jquense mentioned this issue Dec 18, 2017
13 tasks
@KyleAMathews
Copy link
Contributor

V2 fixes this issue so closing!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants