Support named exports with nodejs ESM

[robrichard]

It is currently not possible to use named exports with Relay in a Node.js ESM file. For example, in a brand new project with the latest version of relay-runtime as a dependency, the following code will error:

index.mjs:

import { fetchQuery } from 'relay-runtime'

file:///index.mjs:1
import { fetchQuery } from 'relay-runtime';
         ^^^^^^^^^^
SyntaxError: Named export 'fetchQuery' not found. The requested module 'relay-runtime' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:

import pkg from 'relay-runtime';
const { fetchQuery } = pkg;

    at #asyncInstantiate (node:internal/modules/esm/module_job:302:21)
    at async ModuleJob.run (node:internal/modules/esm/module_job:405:5)
    at async onImport.tracePromise.__proto__ (node:internal/modules/esm/loader:660:26)
    at async asyncRunEntryPointWithESMLoader (node:internal/modules/run_main:101:5)

When an ESM file imports a common js file (like relay-runtime) Node.js will use cjs-module-lexer to try to determine compatible named exports.

From the node.js docs:

Named exports detection covers many common export patterns, reexport patterns and build tool and transpiler outputs. See cjs-module-lexer for the exact semantics implemented.

In the entry points of react-relay and relay-runtime, the pattern of exporting a property on another object causes cjs-module-lexer to not detect any of named exports.

Example:

// This doesn't work
module.exports = {
  fetchQuery: RelayRuntime.fetchQuery
};

// This does work
const { fetchQuery } = RelayRuntime;
module.exports = {
  fetchQuery
};

In this PR, I updated the entrypoints of react-relay and relay-runtime to allow Node.js's cjs named export detection to work properly. I added a test case to the Gulp build process since to test this we need the final transpiled code, but I am open to other approaches.

[captbaritone]

These counts feel brittle. Do we have to come update this magic number anytime we add/remove an export from one of these modules? If that's going to be the case, we likely need comments in each of the export files explaining this coupling.

Is there not some other way to enforce this? ESLint maybe?

[captbaritone]

Or perhaps even better, some Babel transform or similar that can automatically produce the right output from our existing code.

[robrichard]

@captbaritone I removed this test entirely and added a an eslint rule to eslint-plugin-relay-internal. It's turned off by default and enabled only in the package entry files. Let me know what you think.

I went with a lint rule because I'm not sure I'd be able to cover every conceivable case in a babel transform.

[meta-codesync]

@captbaritone has imported this pull request. If you are a Meta employee, you can view this in D99335902.

[meta-codesync]

@captbaritone merged this pull request in 9240507.

[jantimon]

@captbaritone instead of adding workarounds could we please move forward with #4548 instead?