apollographql / eslint-plugin-graphql

:vertical_traffic_light: Check your GraphQL query strings against a schema.
https://www.npmjs.com/package/eslint-plugin-graphql
1.21k stars 103 forks source link

Have a better way of getting the schema, for example a URL #4

Closed stubailo closed 5 years ago

stubailo commented 8 years ago

It would be a hassle to run a build script every time the schema changes, I'm sure there is a simpler way.

Blocks: https://github.com/apollostack/meteor-starter-kit/pull/5

stubailo commented 8 years ago

Reference: https://github.com/jimkyndemeyer/js-graphql-language-service/issues/2#issuecomment-213743149

schickling commented 8 years ago

First of all: Thanks for this great plugin!

This is a great idea and exactly what we tried to facilitate with babel-plugin-react-relay when developing apps with Relay. We've implemented this feature using sync-request due to the limitation of Babel that you just can run synchronous plugins.

I'd be very interested to learn more about the implementation details of the upcoming feature. Maybe we can improve the babel-plugin as well.

stubailo commented 8 years ago

One thing I'm really interested in is standardizing some config about how to reach your server. Maybe something like this:

https://github.com/apollostack/graphql-tools/issues/40#issuecomment-213515423

That way, our different plugins might be able to share information about the server, instead of all being configured separately. What do you think? What info would you need in there for your plugin?

schickling commented 8 years ago

That sounds like a very good idea. The problem with Babel is that it's very limited concerning the way how you pass plugin configuration, therefore we had to provide the config in the package.json. Maybe we come up with some kind of .graphqlrc file?

This is also something worth considering: https://github.com/facebook/relay/issues/1080

stubailo commented 8 years ago

Yeah having support for multiple schemas is something I thought about as well. I wonder how you would specify which queries are against which schema for the linter...

Maybe we come up with some kind of .graphqlrc file?

That's kind of what I meant, yeah - something that sits at the root of your project and all build tools can draw from. Maybe we can start listing requirements here? https://github.com/apollostack/graphqlrc

stubailo commented 8 years ago

@schickling hey, I added you to https://github.com/apollostack/graphqlrc, so if you have time to lay down some ideas feel free to just commit to the README!

thebigredgeek commented 7 years ago

Any progress on this?

schickling commented 7 years ago

Not yet. @stubailo and I have to find a time to finish this once and for all 💪

jamiter commented 7 years ago

Would you consider pointing to a .graphql file directly, instead of a .json file coming from a server or the file system? Maybe this linter could parse that file and use it. Or maybe multiple .graphql files. This way I wouldn't need a server to check my linting rules.

Edit: I say this because the webpack loader and the Meteor build plugin both handle .graphql files directly, so it would be great to point to those files, instead of first having to parse or serve them.

BTW, awesome plugin 😄

Edit2: Looks like it would only require a simple change here: https://github.com/apollographql/eslint-plugin-graphql/blob/master/src/index.js#L153-L154, adding a .graphql file and parsing it. Would a PR for it be considered?

Edit3: We could use this code for it: https://github.com/nodkz/webpack-plugin-graphql-schema-hot/blob/master/index.js#L113-L124

schickling commented 7 years ago

@jamiter the best place to contribute to this discussion is here: https://github.com/graphcool/graphql-config/issues/20

This will soon be released and hopefully also finds its way back to the eslint plugin 🙂

schickling commented 7 years ago

This will be solved by #80 🙂