Gatsby: rewrite gatsby-config & gatsby-node with node 11's experimental ECMAScript modules

[janosh]

Has anyone tried replacing module.exports/require() in gatsby-config.js and/or gatsby-node.js with the experimental import/export syntax introduced in node v11.10.1? I'm interested in advice on how to make the transition, whether or not I should wait and if there are any limitations.

[DSchau]

Not as far as I know--but we'd be super enthused to hear back any findings!

Generally - there's probably _some_ overhead here, but the parsing and evaluating of the config* files usually isn't a bottleneck, so the perf. hit wouldn't seem like it'd be super concerning.

As far as advice... I usually give things a little time to shake out (especially new and experimental features), but at the same time--we wouldn't make any progress if we didn't have those brave few who are trying this type of thing out! If you run into issues that _we_ can help resolve with core changes, we'd love to be in a good spot for people who do want to test this stuff out.

So... please do let us know how this goes!

[janosh]

@DSchau The main obstacle (as far as I understand) seems to be that gatsby develop and gatsby build don't provide a way to run node with the --experimental-modules flag. I haven't looked at this very closely yet but if I'm not mistaken, all that would have to be done is to add the --experimental-modules option here and here. If passed, we need to replace the #!/usr/bin/env node here with #!/usr/bin/env node --experimental-modules.

[wardpeet]

we could move to https://github.com/standard-things/esm to enable esm syntax if required. No need to wait for node 11 😛

[harrysolovay]

@wardpeet I like that solution––esm is a great project. Could you or someone who has familiarity with the Gatsby codebase speak to whether the current caching would play nice with esm's? If so, supporting ESModules would be as easy as adding the require highjack. Would love to be able to use this syntax.

[wardpeet]

We only use require statements in our codebase and we transpile imports to commonjs so I don't think this will give any troubles but I'm not 100% sure on this.

Feel free to test out and report to us ;)

[harrysolovay]

Okay, I'll take a shot at it.

From what I can tell. Here are the changes that need to take place:

1. Creating a helper package that differentiates between ESMs & CJS:

const interopRequire = path => {
  const required = require(path)
  return required.__esModule ? required.default : required
}

1. In packages/Gatsby/src/internal-plugins/internal-data-bridge/gatsby-node, add the require highjack:

require = require(‘esm’)(module)

...Along with––at line 121––swapping out the require with interopRequire

One question: where are the other user-defined config resources being required? I searched for a while but couldn't find exactly where it happens. If anyone could let me know, that would be so so nice. Thanks 💯

[wardpeet]

if you want to test it out just put require = require('esm')(module); in https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/bin/gatsby.js

[harrysolovay]

@wardpeet we'd also have to make some changes to the requires in order to support both CJS and ESMs. Do you know where all of the config files get loaded?

[Grsmto]

Hey, would that mean we could use ESM for plugins?
I'm seeing that right now some plugins are adding huge load of useless content in the final bundle cause of tree-shaking not supported due to commonjs.
For example a plugin I'm using is importing all of Lodash and Ramda which adds about 200kb of script for nothing.

[github-actions[bot]]

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!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[wardpeet]

@grsmto I guess you're talking about frontend code of a plugin, right?

could you maybe share an example?

[Grsmto]

@wardpeet sorry for the poorly detailed comment. That comment is from a while ago and I can't actually remind what I was referring to. I tried to take some time now to test some things but I couldn't figure out that issue again.
I guess you can just ignore that for now! Thanks :)

[github-actions[bot]]

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!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[github-actions[bot]]

Hey again!

It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.
Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to reopen this issue or create a new one if you need anything else.
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks again for being part of the Gatsby community! 💪💜