Investigate compiling node_modules code

[m-allanson]

Summary

Investigate:

Copy CRA's implementation for compiling node_modules with babel-preset-env which will fix problems like #3780

Taken from #3870

[jarreds]

Definitely interested in this. With more modules moving to ES6 and the need to support older browsers (Google bot 👀), this would be wonderful. Currently using old ES5 versions of the problematic modules. Not great.

Even if it's not the default, an easy way to flag compilation of node_modules would be great.

[m-allanson]

This probably won't be done for the initial v2 release.

[ZLevine]

Any idea if this is on the roadmap for the near future?

[pgegenfurtner]

Any news on this? With the new theming capabilities it would be a great addition to extract graphql fragments into a theme. Or could this be achieved in any other way?

[DSchau]

@pgegenfurtner great point! So how we currently handle this now is we leverage the existing APIs we already offer. Longer term--we'd like to not have to do this (e.g. transpile node_modules) but for now, you can just use onCreateWebpackConfig to transpile the current theme.

For an example, check out my blog-theme.

There's some indirection there, so the general idea is as simple as:

exports.onCreateWebpackConfig = function onCreateWebpackConfig({ actions, loaders }) {
  actions.setWebpackConfig({
    module: {
      rules: [
        {
          test: 'gatsby-theme-your-theme',
          use: [loaders.js()],
        },
      ],
    },
  });
}

Definitely your point is well taken that this can be improved.

As far as fragments go--we currently (automatically) inspect fragments in any package named gatsby-theme-*, but longer term, anything added to the themes (currently experimentalThemes) will automatically be loaded and the fragments and graphql queries will be available!

[pgegenfurtner]

@DSchau thank you for your quick response!
Via this issue and your fixing commit I found out about the naming convention with gatsby-theme-*. It works just like I imagined!

Definitely one of the best new gatsby features.

[pgegenfurtner]

@DSchau a new question raised as I'm working with this feature. Is it possible to override a query fragment from a theme? Currently my theme has a file with many fragments in it. A page I'm using the theme, may not have all fields of a fragment, so I would need to override it without the fields.

I seem to can't default export a fragment, but I think I need to to override it? Exmple:

Theme queryFragments.js:

export const menu = graphql`
    fragment Menus on ConfigJson {
        menus {
            primary {
                displayName
                path
                sub {
                    displayName
                    path
                }
            }
            social {
                displayName
                media
                path
            }
            footer {
                displayName
                path
            }
        }
    }
`;

Consuming page queryFragments.js:

export const menu = graphql`
  fragment Menus on ConfigJson {
    menus {
      primary {
        displayName
        path
      }
      footer {
        displayName
        path
      }
    }
  }
`;

When I run this, I always get an error error GraphQL Error Unknown field 'sub' on type '[primary_2]' as the subpages don't exist.

[gatsbot]

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’s 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! 💪💜

[liamfd]

I hope this is the right place to ask this question, I wound up here from the polyfills section of the migration guide via #3870:

Remove explicit polyfills

If your Gatsby v1 site included any polyfills, you can remove them. Gatsby v2 ships with babel 7 and is configured to automatically include polyfills for your code. See Gatsby’s babel docs for more details.

Note: This works for your own code, but is not yet implemented for code imported from node_modules. Track progress of this feature at bullet 5 of this issue.

I'm confused by this because my understanding is that babel-polyfill makes its changes globally (as opposed to injecting things into the scope of each module). That seems to match what its docs say:

The polyfill adds to the global scope as well as native prototypes like String in order to do this.

If that's the case, what does the migration guide mean when it says that this is "not yet implemented for code imported from node_modules"? Shouldn't all code have access to the polyfills injected into the global scope?

Is the issue that, because Gatsby uses useBuiltIns: 'usage', and because out of the box Gatsby does not transpile node_modules, babel may not inject the polyfills required by those node_modules because babel never sees their code?

Also, now that React requires Map and Set, should we assume that we'll need to find a workaround to get it working for older browsers with Gatsby 2?

[m-allanson]

There's a WIP PR that will resolve this: #14111

There's also a plugin that allows you to manually specify node_modules packages to compile: https://www.gatsbyjs.org/packages/gatsby-plugin-compile-es6-packages/

[m-allanson]

Could this be enabled via a CLI flag so people can opt-in or out themselves?

[wardpeet]

We published node_module transpilation in gatsby@2.11.0