fix(gatsby): don't try to statically analyze gatsby-node, require it and examine exports instead

[pieh]

#12263 added API filtering in api-runner-node. This exposed some issues in valid, but pretty unusual cases when babel transpile source code to something like:

"use strict";

Object.defineProperty(exports, "__esModule", {
  value: true
});
Object.defineProperty(exports, "onPreBootstrap", {
  enumerable: true,
  get: function get() {
    return _plugin.onPreBootstrap;
  }
});
Object.defineProperty(exports, "onCreateNode", {
  enumerable: true,
  get: function get() {
    return _plugin.onCreateNode;
  }
});

This is oddly looking, but is valid javascript and we should support that. Making it work with static analisys might be challenging, but for gatsby-node APIs we can just require gatsby-node file and check export keys. We can't really do that for gatsby-ssr and gatsby-browser because it can contain code that will just crash in Node.js context (i.e. JSX).

[KyleAMathews]

👍

[DSchau]

Nicely done. Will pull down locally, but this seems like:

• A reasonable thing to do to begin with
• Fixes a bug
• Adds unit tests validating the fix

So... this is great 🎉

[DSchau]

Validated this works e2e with:

module.exports = {
  createPages() {}
}

exports.createPages = () => {}

and

Object.defineProperty(exports, 'createPages', {
  enumberable: true,
  get() {}
})

and all seem to work pretty flawlessly. There are probably things I missed--but I think moving to Node's require for gatsby-node isolates us more effectively than parsing the exports ourselves.

[Moocar]

I ran into this issue as well. My local site's gatsby-node.js wasn't being picked up. Ran it with this branch and issue is fixed. 👍

[DevSide]

This broke gatsby-node using require('esm'). Any ideas ?