Graphql-shield: Move `@types` packages to `dependencies` from `devDependencies`

[Paulooze]

Bug report

• [x] I have checked other issues to make sure this is not a duplicate.

Describe the bug

I have a following error after running tsc --noEmit:

error TS7016: Could not find a declaration file for module 'yup'

This should be fixed by moving all @types modules to dependencies, not devDependencies (I should not install type definitions for package that is not my dependency.

[open-collective-bot[bot]]

Hey @Paulooze :wave:,

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 backing us.

https://opencollective.com/graphql-shield

PS.: We offer priority support for all backers. Don't forget to add priority label when you start backing us :smile:

[maticzav]

I believe there's an underlying issue to your problem. From my experience, TS libraries pack type definitions in development dependencies because they are part of the development environment. Would you mind composing a short reproduction repository?

[Paulooze]

You are right that they are part of development experience - that's why they should be in listed production dependencies, as devDependencies are not installed when I run npm install graphql-shield. apollo-client, for example ships third party types definitions in dependencies here.

Example: @types/module-x package is in devDependencies, when module-x dependency is declared in peerDependencies. In that case, I, as a consumer, am responsible for installing said package (plus @types package).

In this case, I haven't installed yup, therefore I should not need to install @types/yup (so my typecheck script won't fail).

Hope this helps, great job with this module btw, loving it :)

[maticzav]

Thanks a lot! The reason I am so reluctant with the change is that I have never experienced the bug myself.

If I understand the issue correctly, we should only move @types/yup to dependencies because we use yup during development.

Do you by chance have any other reference to a similar issue?

[Paulooze]

Short answer is yes.

Files src/constructors.ts and src/rules.ts export stuff that uses yup types, therefore they (@types/yup) should be available to the consumer (installing them as production dependencies). Example:

export const inputRule = <T>(
  name: string | ((yup: typeof Yup) => Yup.Schema<T>),
  schema?: (yup: typeof Yup) => Yup.Schema<T>,
) => {
  if (typeof name === 'string') {
    return new InputRule(name, schema(Yup))
  } else {
    return new InputRule(Math.random().toString(), name(Yup))
  }
}

Now, let's say I use inputRule inside my code. My typescript doesn't know what Yup.schema<T> or typeof Yup means, because I don't have @types/yup package installed (as I don't directly use yup package). Hope this make sense. This is a longer answer, because you don't use yup only during development, but also in the distributed package.

[maticzav]

Makes sense now. I will implement the fix by the end of the week.

If you have some spare time, I could merge a PR as soon as it lands.

[maticzav]

:tada: This issue has been resolved in version 5.3.2 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: