Graphiql: SemVer breakage re: NoDeprecatedCustomRule from graphql

[floyd-may]

The graphql-language-service-interface package, in going from version 2.4.2 to 2.4.3, relies on an export from graphql named NoDeprecatedCustomRule. The graphql package added this export in v15.2.0. Furthermore, codemirror-graphql revved its dependency version on graphql-language-service-interface from 2.4.2 to 2.4.3 (requiring this change) when it went from 0.12.3 to 0.12.4. My dependency on graphiql, which worked fine with my version of graphql at 14.x, on the publish of these new packages, started breaking, with a compiler error stating that 'NoDeprecatedCustomRule' is not exported from 'graphql'. Now my package.json needs to pin both codemirror-graphql to 0.12.3 and graphql-language-service-interface to 2.4.2 so that I can remain compatible with graphql at v14.

... * sigh *

Y'all.... this is a mess, and it sucked up a bunch of my time because my builds started failing when I hadn't changed any code. For already-published packages, there's not really much you can do, but in the future, can you _please_ be more aware of this kind of thing? In particular, the peerDependencies for graphql-language-service-interface are incorrect, as this package relies on graphql@^15.2.0 (since it needs NoDeprecatedCustomRule introduced at that version) and appears to no longer be compatible with 14.x.

Thanks for your consideration. Let me know if I can provide any more information.

[kgoggin]

Thanks for posting this @floyd-may - I came here because of the same issue having just installed graphiql in a new project. Your documentation just saved me a ton of time. Hopefully they can address this quickly!

[acao]

hmm... perhaps ill need to lazily import this rule, as it’s supposed to use the deprecated function if the import isn’t present. should have been obvious. thanks for the heads up and apologies for the breakage. i couldn’t find anyone to help me review this PR, but our graphql 15 support was broken. didn’t necessitate this change though. will fix this in a patch release in the next few days hopefully

[acao]

just realized its been open 8 days as well! yikes. well i wouldn’t have been able to work on it had I seen it earlier. does someone want to open a PR to just use the deprecated function?

[acao]

fix addressed in [email protected]

[floyd-may]

Will remove the pinned versions I have, retest, and report back. Thanks for getting on this @acao!

[floyd-may]

Works for me!

[acao]

@floyd-may thanks for identifying it so quickly! this would have rendered so many implementations unusable. this is a wake up call that pushing a @next tag and/or canaries is definitely in order.

[floyd-may]

peerDependencies are... fun... Might I suggest a compile against the oldest acceptable version in the peerDependencies somewhere in the CI/CD chain? That would have definitely caught this.

[acao]

great point, working on something similar to this at work and it makes even more sense here.