Adding lint rules for GraphQL

[vohoanglong0107]

As GraphQL parser has been completed and the analyzer infrastructure has been initialized, we can now start adding lint rules for GraphQL. This discussion serves as a central place to gather ideas for lint rules, discuss whether it makes sense to introduce a specific lint rule to Biome, and track the progress of lint rule development.

graphql-eslint

Lint rules from graphql-eslint

Rule	Description	Notes	Implemented?
alphabetize	Enforce arrange in alphabetical order for type fields, enum values, input object fields, operation selections and more.	This feels more fitting for the upcoming assist feature.	-
description-style	Require all comments to follow the same style (either block or inline).	We need to enforce this on a workspace level.	-
executable-definitions	A GraphQL document is only valid for execution if all definitions are either operation or fragment definitions.	We need to differentiate schemas vs operations files.	-
fields-on-correct-type	A GraphQL document is only valid if all fields selected are defined by the parent type, or are an allowed meta field such as __typename.	We would need to process all schema files in workspace.	-
fragments-on-composite-type	Fragments use a type condition to determine if they apply, since fragments can only be spread into a composite type (object, interface, or union), the type condition must also be a composite type.	We would need to process all schema files in workspace.	-
input-name	Require mutation argument to be always called “input” and input type to be called Mutation name + “Input”.	-	-
known-argument-names	A GraphQL field is only valid if all supplied arguments are defined by that field.	We would need to process all schema files in workspace.	-
known-directives	A GraphQL document is only valid if all @Directives are known by the schema and legally positioned.	We would need to process all schema files in workspace.	-
known-fragment-names	A GraphQL document is only valid if all ...Fragment spreads refer to fragments defined in the same document.	We might need a semantic model for this.	-
known-type-names	A GraphQL document is only valid if referenced types (specifically variable definitions and fragment conditions) are defined by the type schema.	We would need to process all schema files in workspace.	-
lone-anonymous-operation	A GraphQL document that contains an anonymous operation (the query short-hand) is only valid if it contains only that one operation definition.	-	-
lone-executable-definition	Require queries, mutations, subscriptions or fragments to be located in separate files.	-	-
lone-schema-definition	A GraphQL document is only valid if it contains only one schema definition.	-	-
match-document-filename	This rule allows you to enforce that the file name should match the operation name.	-	-
naming-convention	Require names to follow specified conventions.	-	-
no-anonymous-operations	Require name for your GraphQL operations. This is useful since most GraphQL client libraries are using the operation name for caching purposes.	-	-
no-deprecated	Enforce that deprecated fields or enum values are not in use by operations.	-	-
no-duplicate-fields	Checks for duplicate fields in selection set, variables in operation definition, or in arguments set of a field.	-	#3308
no-fragment-cycles	A GraphQL fragment is only valid when it does not have cycles in fragments usage.	We would need to process all fragments in the workspace.	-
no-hashtag-description	Requires to use """ or " for adding a GraphQL description instead of #.	-	-
no-one-place-fragments	Disallow fragments that are used only in one place.	We might need semantic model for this.	-
no-root-type	Disallow using root types mutation and/or subscription.	-	-
no-scalar-result-type-on-mutation	Avoid scalar result type on mutation type to make sure to return a valid state.	-	-
no-typename-prefix	Enforces users to avoid using the type name in a field name while defining your schema.	-	-
no-undefined-variables	A GraphQL operation is only valid if all variables encountered, both directly and via fragment spreads, are defined by that operation.	We would need to process all schema files in workspace.	-
no-unreachable-types	Requires all types to be reachable at some level by root level fields.	We would need to process all schema files in workspace.	-
no-unused-fields	Requires all fields to be used at some level by siblings operations.	We would need to process all operation files in workspace.	-
no-unused-fragments	A GraphQL document is only valid if all fragment definitions are spread within operations, or spread within other fragments spread within operations.	We would need to process all operation files in workspace.	-
no-unused-variables	A GraphQL operation is only valid if all variables defined by an operation are used, either directly or within a spread fragment.	We would need to process all operation files in workspace.	-
one-field-subscriptions	A GraphQL subscription is valid only if it contains a single root field.	-	-
overlapping-fields-can-be-merged	A selection set is only valid if all fields (including spreading any fragments) either correspond to distinct response names or can be merged without ambiguity.	We might need semantic model for this.	-
possible-fragment-spread	A fragment spread is only valid if the type condition could ever possibly be true: if there is a non-empty intersection of the possible parent types, and possible types which pass the type condition.	We would need to process all schema files in workspace.	-
possible-type-extension	A type extension is only valid if the type is defined and has the same kind.	We would need to process all schema files in workspace.	-
provided-required-arguments	A field or directive is only valid if all required (non-null without a default value) field arguments have been provided.	We would need to process all schema files in workspace.	-
relay-arguments	Set of rules to follow Relay specification for Arguments.	-	-
relay-connection-types	Set of rules to follow Relay specification for Connection types.	-	-
relay-edge-types	Set of rules to follow Relay specification for Edge types.	-	-
relay-page-info	Set of rules to follow Relay specification for PageInfo.	-	-
require-deprecation-date	Require deletion date on @deprecated directive. Suggest removing deprecated things after deprecated date.	-	-
require-deprecation-reason	Require all deprecation directives to specify a reason.	-	#3289
require-description	Enforce descriptions in type definitions and operations.	-	-
require-field-of-type-query-in-mutation-result	Allow the client in one round-trip not only to call mutation but also to get a wagon of data to update their application.	We might need semantic model for this.	-
require-import-fragment	Require fragments to be imported via an import expression.	We would need to process all operation files in the workspace.	-
require-nullable-fields-with-oneof	Require input or type fields to be non-nullable with @oneOf directive.	-	-
require-nullable-result-in-root	Require nullable fields in root types.	-	-
require-selections	Enforce selecting specific fields when they are available on the GraphQL type.	We would need to process all operation files in the workspace.	-
require-type-pattern-with-oneof	Enforce types with @oneOf directive have error and ok fields.	-	-
scalar-leafs	A GraphQL document is only valid if all leaf fields (fields without sub-selections) are of scalar or enum types.	We would need to process all schema files in the workspace.	-
selection-set-depth	Limit the complexity of the GraphQL operations solely by their depth. Based on graphql-depth-limit.	-	-
strict-id-in-types	Requires output types to have one unique identifier unless they do not have a logical one. Exceptions can be used to ignore output types that do not have unique identifiers.	-	-
unique-argument-names	A GraphQL field or directive is only valid if all supplied arguments are uniquely named.	-	-
unique-directive-names	A GraphQL document is only valid if all defined directives have unique names.	We would need to process all schema files in the workspace.	-
unique-directive-names-per-location	A GraphQL document is only valid if all non-repeatable directives at a given location are uniquely named.	We would need to process all schema files in the workspace.	-
unique-enum-value-names	A GraphQL enum type is only valid if all its values are uniquely named.	-	-
unique-field-definition-names	A GraphQL complex type is only valid if all its fields are uniquely named.	-	-
unique-fragment-name	Enforce unique fragment names across your project.	We would need to process all schema files in the workspace.	-
unique-input-field-names	A GraphQL input object value is only valid if all supplied fields are uniquely named.	-	-
unique-operation-name	Enforce unique operation names across your project.	We would need to process all schema files in the workspace.	-
unique-operation-types	A GraphQL document is only valid if it has only one type per operation.	-	-
unique-type-names	A GraphQL document is only valid if all defined types have unique names.	We would need to process all schema files in the workspace.	-
unique-variable-names	Enforce unique variable names across your project.	We would need to process all schema files in the workspace.	-
value-literals-of-correct-type	A GraphQL document is only valid if all value literals are of the type expected at their position.	We would need to process all schema files in the workspace.	-
variables-are-input-types	A GraphQL operation is only valid if all the variables it defines are of input types (scalar, enum, or input object).	We would need to process all schema files in the workspace.	-
variables-in-allowed-position	Variables passed to field arguments conform to type.	We would need to process all schema files in the workspace.	-

If you have any suggestion for a lint rule, feels free to comment your ideas in this discussion.

[comatory]

What do you think about adding support for linting GraphQL string constants inside of Typescript files? Basically a port of eslint-plugin-relay: https://github.com/relayjs/eslint-plugin-relay

@captbaritone was there any plan ever to make this part of Relay monorepo? AFAIK there's a plugin system coming in Biome v2

[captbaritone]

No active plans to move where they live, but we do consider these rules part of the core Relay offering including some effort to provide documentation for these rules soon™️

[vohoanglong0107]

There are ongoing works to support embedded languages mentioned here #3334, so I hope that we would eventually support GraphQL embed in Typescript