feat(relay): add esm support

[XiNiHa]

[kwonoj]

Mind elaborate what this PR exactly does? description / test cases?

[XiNiHa]

This PR lets users to use module: 'esm' option to emit top level import and its reference instead of require() calls. I'll add test cases this evening.

[XiNiHa]

Well, just realized it had no test code at all. It feels a bit hard to write all the test codes by myself. Can we continue the review with the current state? @kwonoj

[kwonoj]

I'd be hesitant to review PR without having any proper description or test cases to explain what it does exactly.

[XiNiHa]

This PR lets users to use module: 'esm' option to emit top level import and its reference instead of require() calls.

I thought this is enough for describing what this PR does. Do you need any more details?

[kwonoj]

This PR lets users to use module: 'esm' option to emit top level import and its reference instead of require() calls.

The reason I asked for test case is it is a snapshot to show pseudocode what it looks like for the input / outputs. Single line text doesn't seem to describe it precisely, while I can implicitly see behavior though. After all, having proper PR body serves as documentation for the future search context if we need to look back history, and for me it's hard to say current PR description / body fulfills those purpose.

[XiNiHa]

The current version of Relay plugin receives this input:

import { graphql } from 'relay'

const query = graphql`
  query MyQuery {
    foo { bar }
  }
`

and emits this:

import { graphql } from 'relay'

const query = require('./__generated__/MyQuery__graphql')

However, this is indeed ESM incompatible. Therefore this PR adds new module option to let users change the output to be ESM-compatible, like this:

import { graphql } from 'relay'
import MyQuery__graphql from './__generated__/MyQuery.graphql'

const query = MyQuery__graphql

[kwonoj]

Thanks for the clarification. This helps a lot.

Random thought: what if we honor swcrc's module.type config instead of plugin specifies duplicated option for it again? say, like

//.swcrc
{
 "module": {
   // this controls whole transform to emit either cjs or preserve es6, plugin will honor this
  // ignore (or fallback) not yet supported types (amd, etcs) into cjs for now
   "type" : 'commonjs' | 'es6'
 }
}

This'll probably need upstream swc/core change though, as it needs to deliver swc config into plugin.

[XiNiHa]

That sounds very reasonable. What were the previous opinions from the team about exposing the whole swcrc to plugins? Can it be done without sacrificing anything serious? If there's nothing or tiny problems, I guess it'll be much better to go that way.

[kwonoj]

What were the previous opinions from the team about exposing the whole swcrc to plugins?

It was not included as there was no concrete use case for the first phase of implementation.

Can it be done without sacrificing anything serious?

Plugin will need to deserialize swcrc in addition to plugin's config, which would be small overhead. I wouldn't expect it's critical serious.

[XiNiHa]

I'd then wait until that gets implemented.

[mickdelaney]

Any updates on this ? At present the plugin is not useable with typescript. seems like its very close no ?

[kdy1]

I think it's fine to use ESM imports unconditionally

[XiNiHa]

That sounds reasonable. I'll look into it

[XiNiHa]

Done! Can you review the changes again @kwonoj