relay-tools / tslint-plugin-relay Goto Github PK

eslint-plugin-relay does this here: https://github.com/relayjs/eslint-plugin-relay/blob/master/src/rule-graphql-syntax.js

The rule appears to do the following:

• prohibit ${...} substitutions in graphql-tagged strings.
• require GraphQL operations to be named.
• make sure that graphql.parse works on the query.

This build failed due to Danger not having access to the environment variable. See #9.

Now that TSLint is deprecated in favor of ESLint, is there any interest in porting this project to ESLint? I realize that may sound odd because eslint-plugin-relay exists, but that project appears to be intended for Flow-based projects. I'd be happy to see if that project is interested in adopting the TypeScript rules from here, but if they don't want to, is there any interest in retargeting this project for ESLint so those migrating from TSLint can retain Relay linting?

eslint-plugin-relay does this here: https://github.com/relayjs/eslint-plugin-relay/blob/master/src/rule-compat-uses-vars.js

It enforces conventions used by Relay Compatibility Mode. It does the following:

• requires @relay(mask: false) for locally-defined fragments (fragments that aren't defined in fragment containers).
• requires locally-defined fragments to be stored in matching variable names.
• locally-defined fragments must be used (no unused variables).

exlint-plugin-relay does this here: https://github.com/relayjs/eslint-plugin-relay/blob/master/src/rule-graphql-naming.js

The required message is:

Container fragment names must be `<ModuleName>_<propName>`. '

I think this might already be covered by the Relay compiler (or at least, with the Artsy Relay config). Still, a linter that gave in-editor underlining, errors, and auto-fixing would be worth it.

I'm going to look at eslint-plugin-relay's rules and see what makes sense to port over. I'll list them here and work away on them.

Edit: here's a list of their rules:

• rule-compat-uses-vars.js (#16)
• rule-generated-flow-types.js (#15)
• rule-graphql-naming.js (#14)
• rule-graphql-syntax.js (#12)
• rule-no-future-added-value.js (#13)

I'll check them off as I browse rules.

How do we test custom linting rules? This will be important as we add new rules and accept contribution from external contributors.

eslint-plugin-relay does this here: https://github.com/relayjs/eslint-plugin-relay/blob/master/src/rule-no-future-added-value.js

It appears to just prohibit the literal '%future added value' in queries.

After we do #1.

eslint-plugin-relay does this here: https://github.com/relayjs/eslint-plugin-relay/blob/master/src/rule-generated-flow-types.js

Not a high priority for me personally because I don't use Flow, but we should have this available for users who do.