paljs / prisma-tools

Prisma tools to help you generate CRUD system for GraphQL servers
https://paljs.com
MIT License
684 stars 54 forks source link

Requesting upgrade of deprecated `merge-graphql-schemas` dependency to `@graphql-tools/merge` #127

Closed ZenSoftware closed 4 years ago

ZenSoftware commented 4 years ago

Thank you for the wonderful set of Prisma tools @AhmedElywa. I am working on a project that is using your suite of tools for a Nest+Angular - GraphQL code gen starter project @ZenSoftware/Zen. The Nest GraphQL api will serve for schema delegation to the Pal.js SDL first approach. You can see your tools in action here and here. I would not have been able to solve the N+1 problem for free for all my resolver endpoints without the Pal.js Prisma select plugin. Thanks again!!! 🥳

As for the GitHub issue at hand, I noticed that the merge-graphql-schemas library is now deprecated. Here is the relevant info for the upgrade path: Migration from Merge GraphQL Schemas. I would like to request that the Pal.js code generation tools upgrade to the new @graphql-tools/merge library. Cheers my friend 🍭

AhmedElywa commented 4 years ago

Thanks, @ZenSoftware for your issue I am working right now in upgrade

AhmedElywa commented 4 years ago

you can use the last version 1.2.8

ZenSoftware commented 4 years ago

Thank you for getting that released on such short notice! I just finished integrating the new release. Just a couple things to note here:

  1. The old mergeTypes() function from the merge-graphql-schemas package returned a string.
  2. The new mergeTypeDefs() function from the @graphql-tools/merge package returns a DocumentNode

It is very simple to print a DocumentNode to a string by utilizing the import { print } from 'graphql' function. If anyone needs the old behavior of importing the @paljs/cli code generated typeDefs.ts files, they simply need to do the following:

import typeDefs from './generated/typeDefs';
import { print } from 'graphql';
const typeDefsString = print(typeDefs);

In the future, it is best practice to increment the major version number of you package for release with breaking changes. For example, this release it would have been a good idea to increment to v2.0.0. If anyone has "@paljs/plugins": "^1.0.0" in the package.json, they will install this update, which is a breaking change. If you bump the major version to @paljs/plugins@2.0.0, the community that depends on your packages will know to look at your docs for breaking changes. NPM - About Semantic Versioning . I hope that is helpful information! Cheers my friend! Your Prisma tools are amazing 🍰

AhmedElywa commented 4 years ago

For the type backing from mergeTypeDefs, it's not a problem at all. It's working well. about the version, we didn't have any breaking change in this version to start a new Major version

ZenSoftware commented 4 years ago

Gotcha! I was importing the typeDefs.ts directly from the code generated by @paljs/cli. It must be my particular use case where it is a break change. I'm glad it is working as expected.