search

stubailo / graphqlrc

Idea: a file you can put in the root of your repository to configure various GraphQL tools
7 stars 0 forks source link

Support picking which GraphQL validation rules you're interested in #2

Open stubailo opened 8 years ago

stubailo commented 8 years ago

From this list, at first: https://github.com/graphql/graphql-js/blob/master/src/validation/specifiedRules.js

With more to come later! Eventually we should support defining custom rules.

leebyron commented 8 years ago

I like adding custom rules for various reasons (maybe you're using a code generator that requires additional constraints)

I'm curious if the idea is to also exclude from this list, and if so are there common cases? Ideally we never exclude any of the specification rules, but if there's rationale for why you would want to disable one then perhaps we're missing something else.

stubailo commented 8 years ago

Well, there's this:

https://github.com/apollostack/eslint-plugin-graphql/blob/921d15bcb3edae6219682bb6f1bd677dd03a9add/src/index.js#L38

In general, when you're dynamically putting together fragments/variables/etc, some of those won't be represented in the raw static query string.

leebyron commented 8 years ago

Gotcha - yeah that's true. Using Relay results in some quirks. Though we should be able to add most of those back with better support in the tools.

stubailo commented 8 years ago

Yeah I mean in my ideal GraphQL spec there would be better support for how "fancy" libraries should behave. For example, having the arguments for a mutation inside the query string:

http://docs.apollostack.com/apollo-client/core.html#mutate

It's not nice to have to type the arguments three times, when in theory all of the information is there to just type them twice.

It seems like currently GraphQL is optimized for the case where each query is a standalone chunk of logic that doesn't interact much with the surrounding code (declaring its own arguments being one example).