Initial support for using SDL codegen for GraphQL types

[orta]

Adds a redwood config setting which replaces the graphql-codegen for the API with sdl-codegen

Currently untested/validated because Nx freezes on my computer

Now tested and "works on my computer"

[orta]

As this module is the first one in Redwood which is ESM only (I ported it from Deno) then it was the first case in the codebase where ESM/CJS interact.

This means it was the first time, from the looks of the rest of the codebase, that import("thing") was used. As we target versions of node which all have support for that, I have dropped the babel backporting for the feature so it can be used natively.

[jtoar]

Just to illustrate this change for others, here's some example source code from the CLI:

export const handler = async (options) => {
  const { handler } = await import('./buildHandler')
  return handler(options)
}

And here's the output dist with our current Babel config (Babel transforms await import to an async-like require):

const handler = async options => {
  const {
    handler
  } = await _promise.default.resolve().then(() => (0, _interopRequireWildcard2.default)(require('./buildHandler')));
  return handler(options);
};

And here's the output dist with this change (the code stays the same; Babel changes the spacing a bit but that doesn't matter):

const handler = async options => {
  const {
    handler
  } = await import('./buildHandler');
  return handler(options);
};

[orta]

All of the work happens in the sdl-codegen side, there's a good argument that this is flawed (because what if Redwood changes the shape of this paths object) but I copied the types over into the lib.

I think it's reasonable that at some point I chop this down to just the types from Path which are used, and then you aren't accidentally constrained on the shape of the object for anything but the API side.

[orta]

You use the dmmf to grab this info, but it doesn't include the comments! So, I can't re-use that approach.

[jtoar]

Quick update on CI. At least for the tutorial e2e project, the problem seems to be the lack of file extensions: https://github.com/redwoodjs/redwood/actions/runs/5079837564/jobs/9126084663?pr=8417#step:7:29

Taking the yarn rw dev command as an example, here's the dist:

const handler = async options => {
  const {
    handler
  } = await import('./devHandler');
  return handler(options);
};

The reason for the error (linked above) is that there's no .js on './devHandler'. I know ESM is stricter than CJS about relative imports and requires that they have file extensions, but since the CLI is still a CJS module, I thought it'd be ok.

We can proceed in a few ways:

• add file extensions to the dynamic imports of relative paths in the CLI (I went with this for now)
  • the serve command already includes them

    redwood/packages/cli/src/commands/serve.js

    Line 62 in 79d9cb3

    const { bothServerHandler } = await import('./serveHandler.js')

• change await import of relative files to require
  • I think the change here wouldn't matter since they get transpiled to require statements anyway, but I'd have to double check

It looks like we may also need to set NODE_OPTIONS="--experimental-vm-modules" when running tests.

[jtoar]

Without this conditional, Jest wants us to pass --experimental-vm-modules to node. I tried that and most of our test suites actually worked save for the CLI and codemods. But I figured it may be easier to just disable this config for testing since we only really have one ES module we're importing in the entire framework

[jtoar]

Thanks @orta! Hope you don't mind that I pushed a few commits to get CI going and fix merge conflicts

[jtoar]

Looks like the smoke test is failing because I didn't fix runScriptFunction in the CLI which is used for yarn rw exec and prerender:

redwood/packages/cli/src/lib/exec.js

Line 7 in 79d9cb3

export async function runScriptFunction({

[orta]

No worries, good luck, wonder how I missed that other await import in my search

[Tobbe]

Alternative solution for getting rid of proposal-dynamic-import: #8456
(Ended up landing in the same solution after all...)

[jtoar]

Thanks @orta! Let's get this one in

[orta]

Ace, thanks, now I can port my app to use it full yimr