This repository has been archived by the owner on Sep 25, 2024. It is now read-only.
Enabling graphql-validate-fixtures compatibility with varying file types #2658
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
I apologize in advance if I'm not following some standard discussion-approach your team has laid out before submitting this PR. I had a hard time understanding if you guys were OK with outside contributions on some packages, so I just went ahead with making this.
Background
The impression I'm getting is that
graphql-validate-fixtures
may be in somewhat of a maintenance state, presumably because it solves whatever problem it was created for or its usage may have diminished with the increased influence of graphql-tools. In either case, I think this package is kindof awesome and solves a big problem with the current graphql-mocking solutions. Without going into too much detail, using fixtures to mock graphql queries is a much more useful, and low-maintenance solution at scale in my opinion than the prevailing "dynamic mocking" approach taken bygraphql-tools
.However, the problem I found with
graphql-validate-fixtures
is that it doesn't seem to work with the various filetypes that graphql schemas/queries/types can be declared in these days. Not to mention that it doesn't play well with fragments, or apollo-related stuff.So this PR addresses those issues!
What This PR Does
@graphql-tools/load-files
to read files instead offs-extra
. This does seem to be environment specific. (See known issues)graphql-config
file formatsKnown Issues:
@apollo/client
fixtures by running a copy ofcli.ts
with thets-node
cli. Without it, the following error occurs when the script tries to read in queries declared in typescriptI believe there's likely some way to resolve this through configuration or maybe running the script with node in a way that recognizes es6 syntax, but I've hit a wall with my knowledge in this area, so the simplest solution I could find was just running a direct copy of
cli.ts
locally withts-node
@apollo/client
fixtures and standard graphql fixtures. It has to be one or the other. When using@apollo/client
fixtures, the validation expects the__typename
field on every child, so when it doesn't see that field the validation shows errors for them missing from the fixture. I'm thinking the solution to this would probably be incorporating some way to differentiate between the fixtures. But it doesn't seem like a necessary change yet since (I would think) most projects are probably following one pattern or the other.__typename
field (if it exists). This is likely necessary to ensure fixtures corresponding to fragments do not become stale.Any thoughts on this are welcome!