Implement plugin #10

alloy · 2018-01-19T15:07:17Z

Implement plugin purely based on the language plugin interface.
Make type-checker pass.
Setup test suite.
TS compiler API seems to insist on a filename when parsing code, which relay-compiler currently doesn’t pass. Need to fix this in the plugin PR to pass a File object instead of just source.
Setup an example that can be used to test it actually works.

A few notes:

I removed all unused types. It looks like you were typing all of e.g. graphql-compiler as well? Let’s just move those definitions (including the ones I removed) to DT in that case?
I realised later on that you were using tabs and manually tweaking all code to conform to the existing style took more than a few minutes, so I added prettier with default settings and ran that. Let me know if that’s ok with you, I just came to like it because it removes all faffing around styling 😄

kastermester · 2018-01-19T15:52:30Z

Looks great!

Yeah I typed up a bunch of the types from both packages, which helped a lot in implementing the code, I’m not sure on how stable all the types that are used internally are supposed to be though? Ideally we can end up with quite few type definitions that are needed for this plugin and perhaps put just those on DT? I fear otherwise the typings would just stagnate in the DT repo and potentially be worse than if they weren’t there.
I’m a big fan of prettier, I think the code was formatted with that before as well, just from my global config, using the defaults seems good though, so let’s just go with that :)

Like I said I expect to be able to work on this tomorrow - let me know if there’s anything in particular you’d like me to work on. There’s also always the option of implementing the actual TS transformer that we will need, such that we can actually run a Relay application.

kastermester · 2018-01-19T15:53:27Z

Also just realized we might want to add TSLint to the project as well.

alloy · 2018-01-19T16:23:38Z

Yeah I typed up a bunch of the types from both packages, which helped a lot in implementing the code, I’m not sure on how stable all the types that are used internally are supposed to be though?

Yeah that’s always a tough question, which in this case is one to ask the Relay team.

Ideally we can end up with quite few type definitions that are needed for this plugin and perhaps put just those on DT? I fear otherwise the typings would just stagnate in the DT repo and potentially be worse than if they weren’t there.

Oh I definitely think it’s a good idea to have the types that are needed by the plugin in this repo, just maybe not all the typings for e.g. graphql-compiler. Maybe I was just mistaken in thinking that you wanted to type all of that?

I’m a big fan of prettier, I think the code was formatted with that before as well, just from my global config, using the defaults seems good though, so let’s just go with that :)

Ace 👍

Also just realized we might want to add TSLint to the project as well.

Sounds like a good idea. Will you add that?

alloy · 2018-01-19T17:13:50Z

test/__snapshots__/TypeScriptGenerator-test.ts.snap

+}
+
+~~~~~~~~~~ OUTPUT ~~~~~~~~~~
+TODO


This is generating an error when ran currently.

alloy · 2018-01-19T17:14:04Z

test/__snapshots__/TypeScriptGenerator-test.ts.snap

+}
+
+~~~~~~~~~~ OUTPUT ~~~~~~~~~~
+TODO


This is generating an error when ran currently.

alloy · 2018-01-19T17:14:39Z

test/__snapshots__/TypeScriptGenerator-test.ts.snap

+}
+
+~~~~~~~~~~ OUTPUT ~~~~~~~~~~
+TODO


This is generating an error when ran currently.

alloy · 2018-01-19T17:15:46Z

There seems to be a bug somewhere (either jest itself or the custom snapshot code in relay-test-utils) which leads to the snapshots always being updated and thus the tests seemingly being green when in fact the output does not match.

alloy · 2018-01-19T20:25:42Z

src/TypeScriptTypeTransformers.ts

  enumsHasteModule: string | null | undefined;
  existingFragmentNames: Set<string>;
  inputFieldWhiteList: ReadonlyArray<string>;
  relayRuntimeModule: string;
+  // TODO: Marking these as optional until we determine how we can best make imports work.
+  getGeneratedDirectory?: (name: string) => CodegenDirectory;
+  destinationDirectory?: CodegenDirectory;


@kastermester The last few tests were failing because I wasn’t passing in these that you added. Seeing as relay-compiler doesn’t pass these currently (we can add them of course) and we’re not entirely sure yet how to deal with imported files that have changed location, I’ve disabled the code that uses them for now by making these optional and adding guards for them.

From https://github.com/relayjs/relay-examples/tree/a5e1139906197ceeca70c30cd98cef48e952c04c/todo

alloy · 2018-01-20T00:06:48Z

I think this is ready to be merged and in a state where you can do work on it tomorrow (today).

I renamed the plugin to relay-compiler-language-typescript, the relay-compiler-language- prefix is automatically added when doing relay-compiler --language typescript.

I imported the TODO example and have setup the dependency installation such that it uses our relay-compiler and this plugin. Then running the build task leads to:

~/C/R/t/example [implement-plugin] » yarn build
yarn run v1.3.2
$ relay-compiler --src ./ts/ --schema ./data/schema.graphql --language typescript
HINT: pass --watch to keep watching for changes.

Writing default
ERROR:
Error writing modules:
Error: Could not convert from GraphQL type ID!
    at transformNonNullableScalarType (node_modules/relay-compiler-language-typescript/lib/TypeScriptTypeTransformers.js:35:15)
    at Object.transformScalarType (node_modules/relay-compiler-language-typescript/lib/TypeScriptTypeTransformers.js:11:13)
    at Object.ScalarField (node_modules/relay-compiler-language-typescript/lib/TypeScriptGenerator.js:215:61)
    at visit (node_modules/relay-compiler/node_modules/graphql/language/visitor.js:254:26)
    at Object.visitIR [as visit] (node_modules/relay-compiler/lib/GraphQLIRVisitor.js:35:10)
    at Object.exports.generate (node_modules/relay-compiler-language-typescript/lib/TypeScriptGenerator.js:19:49)
    at node_modules/relay-compiler/bin/relay-compiler:7204:57
    at Generator.next (<anonymous>)
    at step (node_modules/relay-compiler/node_modules/babel-runtime/helpers/asyncToGenerator.js:17:30)
    at node_modules/relay-compiler/node_modules/babel-runtime/helpers/asyncToGenerator.js:35:14

Things to do include:

Getting the example to work
Add more test coverage, e.g. for FindGraphQLTags
Getting fragment reference imports to work well

alloy · 2018-01-20T00:13:55Z

Oh, wait, no; this is the dreaded situation where you have multiple versions of the same package installed. After fixing that the plugin works:

~/C/R/t/example [implement-plugin] » yarn build
yarn run v1.3.2
$ relay-compiler --src ./ts/ --schema ./data/schema.graphql --language typescript
HINT: pass --watch to keep watching for changes.

Writing default
Created:
 - RenameTodoMutation.graphql.ts
 - RemoveCompletedTodosMutation.graphql.ts
 - ChangeTodoStatusMutation.graphql.ts
 - RemoveTodoMutation.graphql.ts
 - MarkAllTodosMutation.graphql.ts
 - AddTodoMutation.graphql.ts
 - TodoApp_viewer.graphql.ts
 - Todo_viewer.graphql.ts
 - Todo_todo.graphql.ts
 - TodoList_viewer.graphql.ts
 - TodoListFooter_viewer.graphql.ts
 - appQuery.graphql.ts
Unchanged: 0 files

✨

alloy · 2018-01-20T09:38:37Z

I’ going to do a bit more work on porting the example app over, but if you get to reviewing and merging this PR before I finish that then please do so, the example app work can go into a new PR.

alloy · 2018-01-20T12:29:39Z

Found one little bug in the current formatGeneratedModule implementation, fix is incoming.

kastermester

This seems good! I left a few comments. I had some issues with installing the packages that were npm pack'd, the hashes weren't the right ones, but I'm not sure if it was because you had installed from older versions of the branches, or if the hash just differs between our computers for some other reasons. Either way I just moved the lock files when I installed it and it all seemed to work just fine.

kastermester · 2018-01-20T12:41:41Z

src/FindGraphQLTags.ts

+                createContainerName(callExpr),
+                taggedTemplate.tag.getText()
+              );
+              addGraphQLTag({


How does the relay-compiler package know which container name this came from?

I don’t quite follow, can you elaborate?

kastermester · 2018-01-20T12:42:12Z

src/FindGraphQLTags.ts

+              taggedTemplate.tag.getText()
+            );
+            addGraphQLTag({
+              keyName: null,


I believe this should also carry a container name with it?

Oh yeah, I thought I had left a comment for this, your original code did not perform any name validation in this code branch and thus there was no keyName variable yet either. Seeing as it wasn’t immediately obvious to me what type of tag this is I wanted to leave it for you to amend.

Oh wait, hah no that’s below.

I assume there’s no keyName here because this is the code branch for when you specify the fragment spec using only a tagged template, i.e. without a map.

Probably would be helpful to add some comments to these various branches and have tests for each of them.

kastermester · 2018-01-20T12:44:17Z

src/TypeScriptTypeTransformers.ts

+export type State = {
+  usedEnums: { [name: string]: GraphQLEnumType };
+  usedFragments: Set<string>;
+  // TODO: Marking these as optional and moved from ‘options’ to ‘state’ until we determine how we can best make imports


Seems good. There's quite a few options here to be honest, and given that we'd need to recompile a file when something it refers to is moved, perhaps my idea of just resolving the relative paths aren't even that good. But there are some other options here as well. We should probably talk to the relay team about this, such that we can also get it fixed for the flow version when not using haste (which i figure most people aren't).

Agreed. Let’s ask for feedback once we have everything except for this part working.

kastermester · 2018-01-20T12:52:14Z

Im curious to know, what are your plans regarding the runtime transformation of the graphql tags? AFAIK not even the official babel one would work, as that also expects commonjs exports. Should i begin working on a typescript plugin that can do what we need? This would also eliminate the need for Babel altogether (which I quite like to be honest).

kastermester · 2018-01-20T12:59:16Z

test/__snapshots__/TypeScriptGenerator-test.ts.snap

+}
+
+~~~~~~~~~~ OUTPUT ~~~~~~~~~~
+export type PersonalityTraits = CHEERFUL | DERISIVE | HELPFUL | SNARKY | %future added value;


Is this the bug you're refering to?

I was not, but it’s a good catch!

#11

This was the bug I was referring to 360a291

alloy · 2018-01-20T13:24:30Z

Im curious to know, what are your plans regarding the runtime transformation of the graphql tags? AFAIK not even the official babel one would work, as that also expects commonjs exports.

I’m not entirely sure if I understood you correct, but I think you’re referring to the issue that I fixed here?

FWIW the example app works at runtime.

Should i begin working on a typescript plugin that can do what we need? This would also eliminate the need for Babel altogether (which I quite like to be honest).

While I think that’s a great idea, I think we can finish this stuff first, seeing as the example app works? (I’m biased, though, as our apps require the babel pipeline for other stuff.)

alloy · 2018-01-20T13:27:16Z

example/tsconfig.json

-    "module": "commonjs",                     /* Specify module code generation: 'none', 'commonjs', 'amd', 'system', 'umd', 'es2015', or 'ESNext'. */
-    // "lib": [],                             /* Specify library files to be included in the compilation:  */
+    "target": "es2015",                          /* Specify ECMAScript target version: 'ES3' (default), 'ES5', 'ES2015', 'ES2016', 'ES2017', or 'ESNEXT'. */
+    "module": "es2015",                     /* Specify module code generation: 'none', 'commonjs', 'amd', 'system', 'umd', 'es2015', or 'ESNext'. */


It’s very important to configure TS to build ES6 modules, otherwise the use of the graphql function would be transpiled like so:

var relay_runtime_1 = require('relay-runtime'); relay_runtime_1.graphql(…);

Which makes it impossible for babel-plugin-relay to pick these up.

🤔 Maybe you were referring to this when you said that Babel can’t deal with the graphql tags yet?

@kastermester re the issues with using babel, just wanna make sure you’ve seen this comment

Yup - this is correct, this is sorta how our current relay classic pipeline works as well.

alloy · 2018-01-20T13:28:44Z

I had some issues with installing the packages that were npm pack'd, the hashes weren't the right ones, but I'm not sure if it was because you had installed from older versions of the branches, or if the hash just differs between our computers for some other reasons. Either way I just moved the lock files when I installed it and it all seemed to work just fine.

Ugh… all this local npm pack faffing is very cumbersome anyways :/

kastermester · 2018-01-20T13:28:52Z

I’m not entirely sure if I understood you correct, but I think you’re referring to the issue that I fixed here?

Ah correct. If the relay team has no problems with that solution then I guess it works just fine.

We use babel at our work as well - but being able to remove it from some parts of our pipeline should make quite a huge impact on the performance of building the app. I'm just not too thrilled at forcing people to use some technology they might not have a need for, but then again there are other projects out there that claim to work without babel, so it is probably fine, and we can leave that until we have finished getting things to actually work.

alloy · 2018-01-20T13:29:27Z

Alright, this is done to be merged 👍

alloy · 2018-01-20T13:30:30Z

Ah correct. If the relay team has no problems with that solution then I guess it works just fine.

I know they’d like other projects to use relay-compiler and relay-runtime, but they’ll have to accept that some other languages just don’t export CommonJS modules 🤷‍♂️

kastermester · 2018-01-20T13:32:59Z

I know they’d like other projects to use relay-compiler and relay-runtime, but they’ll have to accept that some other languages just don’t export CommonJS modules 🤷‍♂️

My plan was to make the following typescript transform:

Locate graphql tags
Compile stuff like:

const myVar = graphql`fragment MyFragment on SomeType { .. }`;

into:

const myVar = require('./__generated__/MyFragment.graphql.ts').default;

This way none of the relay-runtime/react-relay code has to be modified.

kastermester · 2018-01-20T13:36:51Z

Ugh… all this local npm pack faffing is very cumbersome anyways :/

Indeed, not sure if there's a better way around it though?

alloy · 2018-01-20T13:40:10Z

I think your plan for a TS plugin is a great one, if you can reduce the pipeline it‘s always a plus, imo! However, I think the baseline being that relay-compiler plugins don’t require you to write more babel transforms is a nice one nonetheless. We’ll see what they say.

alloy · 2018-01-20T13:41:06Z

If/once we get the plugin changes merged into Relay upstream, that should already reduce the faffing by quite a lot. Then the only one that remains is the example app using the local plugin, not sure yet what a simpler solution is there.

kastermester · 2018-01-20T13:48:49Z

If/once we get the plugin changes merged into Relay upstream, that should already reduce the faffing by quite a lot. Then the only one that remains is the example app using the local plugin, not sure yet what a simpler solution is there.

Well once we publish an npm package for this repo then that could also be a lot simpler I guess.

alloy · 2018-01-20T13:51:25Z

Not sure, it’s ideal if the example app would not rely on an external built of the package so that it’s easy to immediately test changes to the plugin.

kastermester · 2018-01-20T13:52:42Z

True - perhaps some of the projects that deal with the idea of a mono repo could be of use here. It is my understanding that they can help with this sort of thing. I do not have any personal experience with that kind of setup though.

alloy added 5 commits January 19, 2018 15:57

[types] Remove all unused typings.

d854e40

[plugin] Initial implementation

958c8b8

[package] Add prettier with default settings.

a303234

[package] Remove unused dependencies

f613856

[package] Build task

ddfc326

alloy assigned kastermester Jan 19, 2018

[test] Setup test suite using fixtures from relay-compiler

80cf6cc

alloy commented Jan 19, 2018

View reviewed changes

[TypeGenerator] Disable fragment imports for now.

ecd625f

alloy commented Jan 19, 2018

View reviewed changes

alloy added 4 commits January 19, 2018 21:43

[PluginInterface] Add type generator options.

ffdea5a

[PluginInterface] Add file path to tag finder.

4c0c917

[FindGraphQLTags] Add first test.

eebc4f3

[prettier] Run

e29ed58

alloy force-pushed the implement-plugin branch from 21148a4 to e29ed58 Compare January 19, 2018 21:27

alloy added 4 commits January 19, 2018 22:33

[example] Import Relay example

6aa2214

From https://github.com/relayjs/relay-examples/tree/a5e1139906197ceeca70c30cd98cef48e952c04c/todo

[package] Rename to relay-compiler-language-typescript

9a81cb3

[example] Configure dependencies.

6c5ce40

[README] More install instructions.

26e2d1b

alloy changed the title ~~[WIP] Implement plugin~~ Implement plugin Jan 20, 2018

[example] Make sure only 1 graphql package is installed.

70e1891

kastermester self-requested a review January 20, 2018 12:40

alloy added 2 commits January 20, 2018 13:42

[formatGeneratedModule] Remove Flow import syntax.

360a291

[package] Bump to 1.0.0-alpha.2

e5b0ee7

kastermester reviewed Jan 20, 2018

View reviewed changes

[example] Use all available typings thus far and able to launch server.

0db2497

alloy mentioned this pull request Jan 20, 2018

String unions are unquoted #11

Closed

alloy commented Jan 20, 2018

View reviewed changes

kastermester merged commit bf75388 into master Jan 20, 2018

alloy deleted the implement-plugin branch January 20, 2018 13:30

alloy mentioned this pull request Jan 20, 2018

Regarding runtime support #1

Closed

Implement plugin #10

Implement plugin #10

Conversation

alloy commented Jan 19, 2018 • edited Loading

kastermester commented Jan 19, 2018

kastermester commented Jan 19, 2018 • edited Loading

alloy commented Jan 19, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alloy commented Jan 19, 2018

Choose a reason for hiding this comment

alloy commented Jan 20, 2018

alloy commented Jan 20, 2018

alloy commented Jan 20, 2018

alloy commented Jan 20, 2018

kastermester left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kastermester commented Jan 20, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alloy commented Jan 20, 2018

alloy Jan 20, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alloy commented Jan 20, 2018

kastermester commented Jan 20, 2018

alloy commented Jan 20, 2018

alloy commented Jan 20, 2018

kastermester commented Jan 20, 2018

kastermester commented Jan 20, 2018

alloy commented Jan 20, 2018

alloy commented Jan 20, 2018

kastermester commented Jan 20, 2018

alloy commented Jan 20, 2018 • edited Loading

kastermester commented Jan 20, 2018

alloy commented Jan 19, 2018 •

edited

Loading

kastermester commented Jan 19, 2018 •

edited

Loading

alloy Jan 20, 2018 •

edited

Loading

alloy commented Jan 20, 2018 •

edited

Loading