Clean up legacy lint rules #161
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
evanyeung
approved these changes
Apr 23, 2025
evanyeung
left a comment
evanyeung
left a comment
There was a problem hiding this comment.
Thanks for updating this! Just few nits/typos to fix before merging but overall looks good
README.md
Outdated
| Brief descriptions for each rule: | ||
|
|
||
| - `relay/graphql-syntax`: Ensures each `graphql\`\`` tagged template literal contains syntactically valid GraphQL. This is also validated by the Relay Compiler, but the ESLint plugin can often provide faster feedback. | ||
| - `relay/graphql-naming`: Ensures GraphQL fragments and quries follow Relay's naming conventions. This is also validated by the Relay Compiler, but the ESLint plugin can often provide faster feedback. |
README.md
Outdated
|
|
||
| - `relay/graphql-syntax`: Ensures each `graphql\`\`` tagged template literal contains syntactically valid GraphQL. This is also validated by the Relay Compiler, but the ESLint plugin can often provide faster feedback. | ||
| - `relay/graphql-naming`: Ensures GraphQL fragments and quries follow Relay's naming conventions. This is also validated by the Relay Compiler, but the ESLint plugin can often provide faster feedback. | ||
| - `relay/must-colocate-fragment-spreads`: Ensures that when a fragment spread is added within a module, that module directly imports the module which defines that fragment. This prevents the anit-pattern when one component fetches a fragment that is not used by a direct child component. **Note**: This rule leans heavily on Meta's globally unique module names. It likely won't work well in other environments. |
README.md
Outdated
| - `relay/graphql-syntax`: Ensures each `graphql\`\`` tagged template literal contains syntactically valid GraphQL. This is also validated by the Relay Compiler, but the ESLint plugin can often provide faster feedback. | ||
| - `relay/graphql-naming`: Ensures GraphQL fragments and quries follow Relay's naming conventions. This is also validated by the Relay Compiler, but the ESLint plugin can often provide faster feedback. | ||
| - `relay/must-colocate-fragment-spreads`: Ensures that when a fragment spread is added within a module, that module directly imports the module which defines that fragment. This prevents the anit-pattern when one component fetches a fragment that is not used by a direct child component. **Note**: This rule leans heavily on Meta's globally unique module names. It likely won't work well in other environments. | ||
| - `relay/no-future-added-value`: Ensures code does not try to explicly handle the `"%future added value"` typename which Relay inserts as a placeholder for types that might be added to the schema while your app is deployed. |
There was a problem hiding this comment.
"explicly" -> "explicitly"
Also, is this just for enums? Might be nice to specify that
README.md
Outdated
| - `relay/graphql-naming`: Ensures GraphQL fragments and quries follow Relay's naming conventions. This is also validated by the Relay Compiler, but the ESLint plugin can often provide faster feedback. | ||
| - `relay/must-colocate-fragment-spreads`: Ensures that when a fragment spread is added within a module, that module directly imports the module which defines that fragment. This prevents the anit-pattern when one component fetches a fragment that is not used by a direct child component. **Note**: This rule leans heavily on Meta's globally unique module names. It likely won't work well in other environments. | ||
| - `relay/no-future-added-value`: Ensures code does not try to explicly handle the `"%future added value"` typename which Relay inserts as a placeholder for types that might be added to the schema while your app is deployed. | ||
| - `relay/unused-fields`: Ensures that every GraphQL field that is fetched is used within the module that includes it. This helps enable Relay's [optimal data fetching](https://relay.dev/blog/2023/10/24/how-relay-enables-optimal-data-fetching/) |
There was a problem hiding this comment.
nit: maybe subjective, but I think it's slightly clearer to say "the module that fetched it" instead of "the module that includes it"
Contributor
Author
There was a problem hiding this comment.
On yeah, that's confusing. Ended up going the other way replacing "fetched" with "referenced".
README.md
Outdated
| - `relay/must-colocate-fragment-spreads`: Ensures that when a fragment spread is added within a module, that module directly imports the module which defines that fragment. This prevents the anit-pattern when one component fetches a fragment that is not used by a direct child component. **Note**: This rule leans heavily on Meta's globally unique module names. It likely won't work well in other environments. | ||
| - `relay/no-future-added-value`: Ensures code does not try to explicly handle the `"%future added value"` typename which Relay inserts as a placeholder for types that might be added to the schema while your app is deployed. | ||
| - `relay/unused-fields`: Ensures that every GraphQL field that is fetched is used within the module that includes it. This helps enable Relay's [optimal data fetching](https://relay.dev/blog/2023/10/24/how-relay-enables-optimal-data-fetching/) | ||
| - `relay/function-required-argument`: Ensures that `readInlineData` is always passed an explict argument even though that argument is allowed to be `undefined` at runtime. |
README.md
Outdated
| - `relay/no-future-added-value`: Ensures code does not try to explicly handle the `"%future added value"` typename which Relay inserts as a placeholder for types that might be added to the schema while your app is deployed. | ||
| - `relay/unused-fields`: Ensures that every GraphQL field that is fetched is used within the module that includes it. This helps enable Relay's [optimal data fetching](https://relay.dev/blog/2023/10/24/how-relay-enables-optimal-data-fetching/) | ||
| - `relay/function-required-argument`: Ensures that `readInlineData` is always passed an explict argument even though that argument is allowed to be `undefined` at runtime. | ||
| - `relay/hook-required-argument`: Ensures that Relay hooks are always passed an explict argument even though that argument is allowed to be `undefined` at runtime. |
README.md
Outdated
Comment on lines
55
to
57
| Haste? | ||
|
|
||
| - `relay/must-colocate-fragment-spreads`: Ensures that for every fragment spread, the module that defines that fragment is imported. |
There was a problem hiding this comment.
Is this left in by accident? This is already documented above!
Contributor
Author
There was a problem hiding this comment.
Oh I missed this. I don't think "haste" is a thing that people know about outside of meta, so I'll delete this in favor of what I have above.
| rules: { | ||
| 'relay/graphql-syntax': 'error', | ||
| 'relay/compat-uses-vars': 'error', | ||
| 'relay/graphql-naming': 'error', |
There was a problem hiding this comment.
I think this line got deleted instead of the compat-uses-vars above
facebook-github-bot
pushed a commit
to facebook/flow
that referenced
this pull request
Apr 23, 2025
Summary: I'm trying to deprecate some lint rules which were made obsolete by this amazing integration and would like something public I can point to. relayjs/eslint-plugin-relay#161 Reviewed By: jbrown215 Differential Revision: D73521437 fbshipit-source-id: e54a519465ec3c1ca966373515bc7f8a70dce349
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We had two lint rules which are no-longer relevant.
relay/compat-uses-varswas oriented around enabling migration from Relay classicrelay/generated-flow-typeswas used to ensure hooks/functions in Flow were passed type arguments that matched the fragment/query used. Flow can now understands thatgraphqltagged template literals resolve to Relay imports. This means we don't need to supply these type arguments any more.I've also tired to at least add a description to for each lint rule. We really need a documentation page for each rule, but this is at least a start.