Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for .graphqlconfig #80

Merged
merged 1 commit into from
Jul 31, 2017
Merged

Add support for .graphqlconfig #80

merged 1 commit into from
Jul 31, 2017

Conversation

RomanHotsiy
Copy link
Contributor

@RomanHotsiy RomanHotsiy commented Jul 21, 2017

Add support for .graphqlconfig

This PR is backward compatible as it doesn't remove any already existed configuration options. It just adds support for .graphqlconfig as a way to configure schema.
That's why I made schemaJson , schemaString and schemaJsonFilepath not required (but they still are mutually exclusive)

cc @jnwng

@apollo-cla
Copy link

@RomanGotsiy: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Meteor Contributor Agreement here: https://contribute.meteor.com/

@jnwng
Copy link
Contributor

jnwng commented Jul 24, 2017

awesome @RomanGotsiy! this addresses one of our oldest issues, #8. let me just confirm that this does what we expect with our existing configuration options, and i'll cut a release soon thereafter

@RomanHotsiy
Copy link
Contributor Author

@jnwng amazing! Thanks for the update!

@schickling
Copy link

Any update on this @jnwng? 🙂

src/index.js Outdated
@@ -120,14 +128,11 @@ export const rules = {
},
},
// schemaJson, schemaJsonFilepath and schemaString are mutually exclusive:
oneOf: [{
required: ['schemaJson'],
allOf: [{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

something is a little off about this configuration validation. my assumption is that projectName should be mutually exclusive with schemaJson, schemaString, and schemaJsonFilepath, so this configuration validation should reflect that.

additionally, we'd like to make sure that those validations only happen when those configuration properties are present, and if they're not present, it should still be valid.

there's also a section here that i think needs to match this configuration as well. can we just extract this configuration key validation and use it for all the rules?

Copy link
Contributor

@jnwng jnwng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

chatted offline with @RomanGotsiy to make sure that the configuration validation correctly took into account the projectName property

@RomanHotsiy
Copy link
Contributor Author

hey @jnwng

Just updated PR according to your requirements

@jnwng jnwng merged commit 6a242a1 into apollographql:master Jul 31, 2017
@jnwng
Copy link
Contributor

jnwng commented Jul 31, 2017

thank you @RomanGotsiy!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants