Add ability to share configs
Opened this issue ยท 4 comments
Have you thought about supporting something like ESLint shareable config?
{
"graphql-schema-linter": {
"extends": "some-package-name",
"rules": ["additional-rule"],
"schemaPaths": ["path/to/my/schema/files/**.graphql"]
}
}
Rules from extends
package would be implied, and customRulePaths
in the config package would need to be relative to that package directory.
If this is something you would merge, I can look into making a PR.
Hey Eric!
Thanks for opening this issue. ๐ This is actually the first time I read about ESLint shareable config.
I'm not against adding this, but out of curiosity, how would this change your current workflow? What would become easier with this feature?
@cjoudrey This is related to the other issue I submitted: #216
We are breaking up the API into various plugins and microservices, each of which will live in its own repository. So we need identical GraphQL linter checks in every project, and because we have custom rules, that means that custom rules folder also needs to be copied into every project. We don't want to duplicate that code and have to do rule fixes in 50 repos.
So my thought was to make an NPM package that contains the custom rule files plus our config object. Then in each project we would install both graphql-schema-linter
and our package and do the project config as:
{
"graphql-schema-linter": {
"extends": "@reactioncommerce/graphql-schema-linter-config",
"schemaPaths": ["path/to/my/schema/files/**.graphql"]
}
}
Additionally, our users write custom plugins that extend the Reaction GraphQL API, so this would allow them to easily ensure identical GraphQL patterns in custom plugins, too.
(Even if we merge most of our custom rules into the main package as I proposed, there's still one custom rule we need because we did our Relay pagination types slightly differently from what's in the built-in rule.)
So we need identical GraphQL linter checks in every project, and because we have custom rules, that means that custom rules folder also needs to be copied into every project. We don't want to duplicate that code and have to do rule fixes in 50 repos.
That's a really interesting idea. I like it. ๐ I'd be happy to accept this feature if you're interested in contributing it. ๐
we did our Relay pagination types slightly differently from what's in the built-in rule
Out of curiosity, what do you do?
@cjoudrey We have a custom type ConnectionLimitInt
rather than Int
for first
and last
.
An integer between 1 and 50, inclusive. Values less than 1 become 1 and values greater than 50 become 50.
This was done for performance reasons to help enforce maximum results on every query without developers needing to remember, but in hindsight it probably wasn't a good idea. We're stuck with it until we're ready to do a breaking release to change it, though.
I'll work on a PR for sharing rules and configs in packages.