Note that this PR branches from #227, which branches from #226, so if possible it makes sense to merge these PRs in the order they were created.
Currently, we expect developers to run the graphql-codegen step locally and commit the resulting files. However, we have found in other projects that this approach has its downsides:
Since the output of graphql-codegen step is basically a function of all our other checked-in code (Drupal configs + application code), it doesn't really make sense on principal to commit it, when we can generate in CI.
Generating codegen during CI guarantees it's correct "as the computer sees it", and there aren't issues due to a dev forgetting to push changes or similar.
Our current approach can cause many conflicts when lots of content types are added in a short space of time, requiring lots of frustrating merges/rebases in feature environments that otherwise shouldn't be necessary.
See relevant commits for more details:
99a8485fc6a3c6cb60b5eadab56fefc9d0514e03
a25de71d2a1a47ba55beb648afb40c42c48d3cdd
693e8e8f43f4ed2684afbc3ae2b2d528bf97c269
1570e231e23447b70b1f011b4d6379f277df6c1c
How to test:
Checkout this branch, run the usual ./setup.sh -c
Run lando npm run dev and change some graphql things (fragments/queries etc), does it work like you'd expect (i.e. changes are updated as you make them)?
Check the Next.js feature env and build logs, any surprises there?
Link to feature environment:
Drupal Next.js Storybook
Changes proposed in this PR:
Note that this PR branches from #227, which branches from #226, so if possible it makes sense to merge these PRs in the order they were created.
Currently, we expect developers to run the
graphql-codegenstep locally and commit the resulting files. However, we have found in other projects that this approach has its downsides:See relevant commits for more details:
How to test:
./setup.sh -clando npm run devand change some graphql things (fragments/queries etc), does it work like you'd expect (i.e. changes are updated as you make them)?