graphql-schema-linter
graphql-schema-linter copied to clipboard
cjoudrey
Validate GraphQL schema definitions against a set of rules
Non-null Int types for "first" argument are not accepted by rule "relay-connection-arguments-spec"
The following queries all fail lint checks: ```graphql notablePeople(first: Int!, after: ID): NotablePersonConnection! users(first: Int!, after: ID, where: UsersQueryWhereInput): UserConnection! @requireOneOfRoles(roles: [MODERATOR]) notablePeopleEvents( first: Int! after: ID where: NotablePersonEventsQueryWhereInput ):...
Many have argued that the default behavior of Arrays in the schema should be `[Obj!]!`: ex: ``` type Foo { bars: [Baz!]! } ``` Most of the time, when you...
Hi, first thanks for your work in this project! I'm using the linter in a project where I don't use Relay, and I have some errors with the relay rules....
Although we aren't defining the rules the way ESLint expects, we might be able to add a module that makes the linter work with ESLint. For example: https://github.com/azeemba/eslint-plugin-json/blob/d2d48e30e17d9d4e7c62455ceffbd8338cd5b083/lib/index.js#L25 Another example:...
I'm trying to create an interface that specifies what a `Connection` must implement. However, the rule `relay-connection-types-spec` prevents this from happening. The following schema seems perfectly valid to me. I...
Add a new rule called `relay-edge-types-spec` that covers: https://facebook.github.io/relay/graphql/connections.htm#sec-Edge-Types
The goal of this rule is: - To push API clients off deprecated fields by letting them know when a field will get removed. - Encourage API owners to remove...
One issue I'm finding with making my schema more consistent is that enabling certain rules requires adding documentation where it may be noisy, for example with `arguments-have-descriptions`, where all of...
A bit of background, we're working with a Federated Schema, built using TypeGraphQL and Apollo. As a quality measure, I want to implement schema linting, to help us maintain this...
