Gatsby: Make computed Babel configuration accessible in Node API

Created on 1 Jan 2019  路  12Comments  路  Source: gatsbyjs/gatsby

Summary

It would be very useful to be able to access Gatsby's computed Babel configuration in the Node API, especially when developing plugins.

Basic example

To make the final API consistent it would probably have to be a breaking change because getConfig in onCreateWebpackConfig would need to become getWebpackConfig, but a non-breaking version of the API might look like this:

exports.onCreateBabelConfig = ({ actions }) => {
  actions.setBabelPreset({
    name: 'linaria/babel'
  })
}

exports.onCreateWebpackConfig = ({ actions, getConfig, getBabelConfig, stage }) => {
  // returns Babel configuration AFTER applying "linaria/babel" preset
  console.log(getBabelConfig())
}

Motivation

I'm building a plugin which consists of a Babel preset and a webpack loader. The webpack loader is looking for the project's Babel configuration, but instead I want to pass it Gatsby's computed Babel configuration, so that people using my plugin don't have to create a custom Babel configuration on their own to make my Gatsby plugin work.

help wanted stale?

All 12 comments

This should be easy to do I think since we already have the applied config in redux. @pieh can confirm this

@silvenon this is a bit more advanced but have you tried https://www.gatsbyjs.org/docs/add-custom-webpack-config/#modifying-the-babel-loader

I'm unsure what the best practices are here and that we even want to expose babelConfig. maybe @pieh or @DSchau can help.

@wardpeet yes, that's how I was planning to modify the webpack configuration to add another loader after babel-loader, but I need to pass the computed Babel configuration object to that loader as options. Did I understand you correctly?

@silvenon From the documentation page that @wardpeet linked to

// Unless you're replacing Babel with a different transpiler, you probably
// want this so that Gatsby will apply its required Babel
// presets/plugins. This will also merge in your configuration from
// babel.config.js.
...loaders.js(),

This is evaluate down to

{ options: undefined,
  loader:
   'node_modules/gatsby/dist/utils/babel-loader.js' }

Adding anything else inside the object where loaders.js is spread will let you add _overrides_

If I understand your use case correctly, your plugin should be able to add its overrides here

AFAIK, node_modules/gatsby/dist/utils/babel-loader.js is where the Babel config merging logic happens. I want to get that config and pass it to my loader as well. Here's some code (I'm using rules instead of loaders because it's easier):

exports.onCreateWebpackConfig = ({ rules, getBabelConfig }) => {
  const jsRule = rules.js();
  const jsRuleWithMyLoader = {
    ...jsRule,
    use: [
      ...jsRule.use,
      {
        loader: 'my-loader',
        options: {
          babelConfig: getBabelConfig(),
        }
      },
    ],
  };
  // ...merge with the webpack config...
}

If I leave this option blank, my-loader will only pick up Babel configuration from babel.config.js. If I happen to be using gatsby-plugin-flow which modifies Babel config, my-loader won't know about it.

Sorry if I'm not getting it, can you show me what I can do to point my plugin to the right direction?

Btw, exposing this config might also be a good step toward making it accessible to babel-eslint and babel-jest, without having to replicate changes made by Gatsby plugins in babel.config.js. But that's another story.

I've talked this through with @pieh & @DSchau and we agreed that it's a handy feature. Sadly it's not widely requested and only used for a few libraries on the web like linaria. We have other priorities atm so if you want to take a stab at it, that would be awesome! 馃檶

That's ok 馃槃 This is open source, there are no expectations, I'm happy that you're considering it at all. 馃槈

We're happy to help you giving pointers on where to get started 馃槃

If I catch some time and dive into it, I'll ask questions then. 馃槃

Hiya!

This issue has gone quiet. Spooky quiet. 馃懟

We get a lot of issues, so we currently close issues after 30 days of inactivity. It鈥檚 been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

Thanks for being a part of the Gatsby community! 馃挭馃挏

You're right, gatsbot, no need to keep this open. I'll submit a PR when or if I get around to it.

Was this page helpful?
0 / 5 - 0 ratings