Add basic external transformation support to relay-compiler

[s-panferov]

Hello, thanks for the great library. We are using TypeScript for our codebase and it will be very useful to enable custom pre-transformations for a source code before parsing, so we can compile our typescript modules without complex configuration. The PR adds such support.

It is a very basic implementation for discussion purposes.

Proposed usage:

yarn add  relay-compiler-typescript
relay-compiler --transform relay-compiler-typescript --extensions ts tsx js jsx

You can find example transformer implementation here: https://github.com/s-panferov/relay-compiler-typescript/tree/master

[facebook-github-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at cla@fb.com. Thanks!

If you are contributing on behalf of someone else (eg your employer): the individual CLA is not sufficient - use https://developers.facebook.com/opensource/cla?type=company instead. Contact cla@fb.com if you have any questions.

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

[leebyron]

Very interesting! Could you ensure lint passes?

[s-panferov]

@leebyron it fails on a global variable which linter doesn't know (__non_webpack_require__). I'll try to figure out how to add a global variable to the linter

[miracle2k]

While I've had very good success so far just running relay-compiler over my .ts and .tsx files, one thing relay-compiler cannot parse is a foo as any cast in a .tsx file.

[kassens]

I'm starting work on simplifying the graphql extraction to no longer fully parse which should also make it work for ts! \o/

[voxmatt]

Any updates here? This is super-interesting.

[josephsavona]

cc @wincent - could we use this to require the persist module?

[wincent]

Probably. I need to re-test my PR. If it doesn't work can try this "one weird trick".

[kassens]

Sorry for the delay here. My plan to pull out the GraphQL tags using a simplified state machine parser didn't work out because I wanted to avoid false positives such as a graphql`` tag appearing inside a string or other edge cases.

I'll send a commit soon that enables parsing of pure .graphql files using a second parser config instead of RelayFileIRParser. This should show pretty clearly how you could add a TypescriptFileIRParser.

[bchenSyd]

mocha has an option called --compilers where you specify the file extension and a js bootstrap file (mostly babel-register and node-ts/register) which hooks up to node's module resolution method.

after that, node will consult the right transpiler when it resolve a module. for all registered module files like .js/.jsx/.ts/.tsx files node will call the corresponding transform method before putting into its module system. so from mocha's point of view, everything is plain es5.

i think its a good solution. dont call their transform function explicitly, but let node calls their module hook ups and only take es5 as input. I think jest and relay-compiler can take the same approach

[voxmatt]

@kassens (or anyone) have you figured out a work-around in the meantime. Without the ability to run relay-compiler against our Typescript codebase, it's not really possible to run in development mode (we use webpack dev server).

[jdolle]

@voxmatt I am currently working on this very problem. My workaround was to move the graphql call to a .js file and then import that in my component.ts. You have to set allowJs: true in the tsconfig but otherwise seems like a good temporary solution. Let me know if that works for you.

[alloy]

Rebased this branch and fixed the linter issues https://github.com/s-panferov/relay/pull/1

[lukewlms]

@jdolle @voxmatt Could you explain to me the complication you're trying to fix? We have this simple build config set up under npm build and it works well with Relay, but there may be an optimization we're lacking.

1. tsc (src -> dist)
2. relay-compiler on JS files in dist directory
3. babel on JS files in dist directory

Our project is still fairly simple, are there aspects of more complicated projects you're seeing where this setup breaks?

In our tsconfig.json we use these to make sure graphql tags are properly picked up by Babel:

    "target": "esnext", // babel handles downtranspiling
    // module: es2015 is required for TypeScript to properly output graphql
    // tags
    "module": "es2015", 

[voxmatt]

When using webpack-dev-server, there is no dist folder to run the relay-compiler on. We need either (a) some way to run the compiler against ts files without failing (this is preferable and seems pretty close to doable since it's just getting hung up on superfluous syntax) or (b) run the compiler in a step that webpack runs.

Previously, with relay-classic, this worked because relay relied on the babel plugin alone and babel is a loader in our webpack config; so, the babel step was handled in the dev-server setup.

[lukewlms]

@voxmatt Very much appreciate the explanation - clipped for when we're building out the web version of our app.

[leebyron]

Hey @wincent, could you please look at this issue? We should make a decision as to whether this fits into the relay-compiler or not

[leebyron]

Also - this PR no longer merges cleanly. @s-panferov would you mind rebasing?

[wincent]

Hey @wincent, could you please look at this issue? We should make a decision as to whether this fits into the relay-compiler or not

I think it makes sense for something like this to be in "relay-compiler". Even if we don't go all the way to having a general pluggable transform mechanism like this, we know the concrete TypeScript use-case would be valuable to solve.

For me the main question is which of these is most desirable:

• Generic fast parser as proposed by @kassens (which he ended up punting on due to concerns about false positives).
• Pluggable transform as shown in this PR.
• Closely related to this idea of augmenting the parser, making it simple to replace it by creating and using a simple TypeScriptParser (which could either be a true parser like RelayJSModuleParser which ultimately uses Babylon to parse JS, or a crude text-based matcher like this one). For reference, the simplest alternative parser is the DotGraphQLParser.

My gut sense that the second path (the one implemented in this PR) feels like a good approach. We don't yet have a good story for how you can swap pieces in and out of the compiler (short of making your own module which involved a bit of copy-pasta), and adding a --transform switch doesn't seem like too much API creep.

[alloy]

In our case I decided to go with a very simple stopgap solution and start experimenting with Babel 7, which has a TS parser, asap.

[robrichard]

Should this feature be called something other than transform to avoid confusion with compiler transforms?

[miracle2k]

I ported this patch to relay 1.3.0, get it here: miracle2k@eda4f6b

[jimkyndemeyer]

@alloy Do you have an update on using Babel 7? We use TypeScript with Relay Classic and this issue is preventing us from upgrading to Modern.

[alloy]

@jimkyndemeyer Oh yes! I had ported our React Native app to use Haul, which is webpack based, and was able to use Babel 7 without tsc with great success artsy/emission#780 🎉

The main issue I encountered was that the TS and Flow plugins for Babel can’t be active at the same time, so I had to strip all node_modules of flow typings that were present in libraries after installing dependencies, but iirc Relay doesn’t ship with Flow typings left in (only React and React Native do), so that shouldn’t be an issue.

The reason I haven’t brought it to completion yet is that we decided to switch back to the default RN packager (Metro) and alas I haven’t yet been able to get Babel 7 to work with that setup, but I didn’t spend much time on that yet either. If you use webpack, this shouldn’t be an issue for you and you can largely follow what I did in that linked PR.

Addendum: the Babel 7 TS plugin does not support namespaces and const enums, so if you require those you’re out of luck.

[mattias800]

Any news on this? Would be great if we got proper TS support in the Relay compiler.

I've written a simple Typescript transformer which replaces the babel relay plugin. You can use it if you want to use the TS compiler instead of Babel 7.
https://github.com/mattias800/relay-modern-typescript-transformer

[darting]

Hi all .. any news on this? many thanks

[alloy]

As part of work I’m finishing up over the week to add TS type info to artefacts, I’m also working on a very simple plugin API, but in fact my work will also already support TS parsing by using Babel 7.

[alloy]

For people subscribed to this PR, I just pushed a new PR that adds plugin support and a link to a TS plugin. #2293

[alloy]

@jstejada I would say that by now this can be closed in favour of #2293.

[alloy]

Wow, I don’t know how I could have unassigned @wincent 👻

🤷‍♂️