dotansimha
commented
1 year ago Thank you @jdolle !
We need to onboard existing schemas that do not conform to our desired set of linting rules, but want to prevent any new non-compliant schema changes from ending up in our supergraph.
This is a very interesting idea, and we do want to explore the option to support this kind of linting process for the schema policy checks.
As a (very) hacky workaround, I can propose to use a warning in the meantime, and use the #eslint-ignore directives on the parts of the schema that you might want to ignore.
I'm not too familiar with Hive's codebase yet so I'm not sure if linting runs with compatibility or on push.
We are using ESLint under the hood, and running https://github.com/B2o5T/graphql-eslint . Theoretically, we can use any ESLint plugin to achieve this kind of functionality. As it's not supported as part of ESLint's core, @B2o5T suggested that maybe we can integrate https://www.npmjs.com/package/eslint-plugin-diff into the process (or a similar plugin), and then allow Hive users to run the linting process only for the changed parts of the schema.
Use case: We need to onboard existing schemas that do not conform to our desired set of linting rules, but want to prevent any new non-compliant schema changes from ending up in our supergraph.
Proposed Solution: We'd like to be able to optionally only run linting against any new changes to a target's schema. The initial push may need to be a force push or as part of this setting, it may ignore the first push of a schema. I'm not too familiar with Hive's codebase yet so I'm not sure if linting runs with compatibility or on push.
It may be nice to somehow show the existing linting errors as well so teams are aware of these issues, but they should not block compatibility/publishing.