@types/yup dev dependency
gcourtemanche opened this issue · comments
Question about GraphQL Shield
Is it a mistake that @types/yup is listed as a dependencies and not a devDependencies? If not, why do you need it as a dependency? Thank you!
- I have checked other questions and found none that matches mine.
Hey @gcourtemanche 👋,
Thank you for opening an issue. We will get back to you as soon as we can. Also, check out our Open Collective and consider contributing financially.
https://opencollective.com/graphql-shield
PS.: We offer
prioritysupport for all financial contributors. Don't forget to addprioritylabel once you start contributing 😄
Hey! It's not a mistake because it is exposed to other users. Perhaps it'd be better if it were a peer dependency though, but I don't think it changes much because we expose the constructor from shield.
It is a problem for us because it causes weird errors in our yarn workspaces if we don't have the same version. I think a peer dependency would be good.
@Sytten I get it that you might need to use another version of Yup for other things besides graphql-shield. It seems to me, however, that following this approach, we could make all dependencies peer-dependencies which doesn't feel right.
Following the article in https://nodejs.org/en/blog/npm/peer-dependencies/, I don't think yup qualifies as a peer-dependency per se. shield is not a plugin to yup, we use yup internally. I don't think you ought to import any yup method from yup itself and instead only use the one shield exposes.
From my point of view, we either move both yup and @types/yup to peer-dependencies or keep them as they are. The idea behind this is that if types mismatch in your version and the one shield uses, you'd have to tell ts-compiler to skip types lib-check, which seems even worse.
Maybe I am missing something, what do you think?
I agree that both libs should move to the peer if it is decided to move them there. It is similar to packages that depend on express because in the end it's the yup version of the user that is provided to graphql-shield in the form of rules and it is not just something used internally.
That change should come with some documentation too for existing user. I am not sure if this is a breaking change, but I would but major personally because it could break the workflow of people.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
We were able to resolve our mismatch issue with @types/yup.
We were able to resolve our mismatch issue with @types/yup.
How did you resolve it? Is this still relevant then?
We did a refresh of our lockfile so most likely graphql-shield picked up the new version of types since the version is not pinned but uses ^.