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

Investigate compiling node_modules code #7064

Closed
m-allanson opened this issue Aug 6, 2018 · 12 comments
Closed

Investigate compiling node_modules code #7064

m-allanson opened this issue Aug 6, 2018 · 12 comments
Assignees
Labels
type: question or discussion Issue discussing or asking a question about Gatsby
Milestone

Comments

@m-allanson
Copy link
Contributor

Summary

Investigate:

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

Taken from #3870

@m-allanson m-allanson added the type: question or discussion Issue discussing or asking a question about Gatsby label Aug 6, 2018
@jarreds
Copy link

jarreds commented Aug 18, 2018

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
Copy link
Contributor Author

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

@ZLevine
Copy link

ZLevine commented Sep 20, 2018

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

@pgegenfurtner
Copy link
Contributor

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
Copy link
Contributor

DSchau commented Jan 9, 2019

@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
Copy link
Contributor

@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
Copy link
Contributor

@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
Copy link

gatsbot bot commented Feb 14, 2019

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

@gatsbot gatsbot bot added the stale? Issue that may be closed soon due to the original author not responding any more. label Feb 14, 2019
@pieh pieh added not stale and removed stale? Issue that may be closed soon due to the original author not responding any more. labels Feb 14, 2019
@liamfd
Copy link

liamfd commented Mar 20, 2019

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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

@wardpeet
Copy link
Contributor

We published node_module transpilation in gatsby@2.11.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: question or discussion Issue discussing or asking a question about Gatsby
Projects
None yet
Development

No branches or pull requests

9 participants