Type error: TypeBoxTypeProvider does not satisfy the constraint FastifyTypeProvider

[myftija]

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure the bug has not already been reported

Fastify version

4.24.3

Plugin version

3.5.0

Node.js version

18.15.0

Operating system

macOS

Operating system version (i.e. 20.04, 11.3, 10)

Ventura 13.5.1

Description

TypeBoxTypeProvider produces a type error in version 3.5.0. I am not facing this issue in version 3.1.0.

Steps to Reproduce

import Fastify from 'fastify'
import { TypeBoxTypeProvider } from '@fastify/type-provider-typebox'

const fastify = Fastify().withTypeProvider<TypeBoxTypeProvider>()

This produces a type error:

error TS2344: Type 'TypeBoxTypeProvider' does not satisfy the constraint 'FastifyTypeProvider'.
  Property 'input' is missing in type 'TypeBoxTypeProvider' but required in type 'FastifyTypeProvider'.

Typescript version: 5.0.4

Expected Behavior

No response

[mcollina]

I cannot reproduce. Can you push your file and tsconfig to a repo?

[paulius-valiunas]

@mcollina this happens when using pnpm, and probably recent versions of yarn (I haven't tried them but I've heard they're more restrictive than npm). You don't explicitly declare fastify as a dependency or peerDependency, but still import it in index.d.ts, which makes it a phantom dependency. It's all fine if the consumer is using npm, because npm allows phantom dependencies. But if they use pnpm, when you try to import FastifyTypeProvider from fastify, you get an unknown type because fastify is not declared as a dependency and thus not accessible from your modules:

Workaround:

Adding this to my package.json fixed the issue for me:

"pnpm": {
  "packageExtensions": {
    "@fastify/type-provider-typebox@^3.6.0": {
      "peerDependencies": {
        "fastify": "^4.16.0"
      }
    }
  }
}

Needless to say, I think it should be permanently fixed by adding the peerDependency to your package.

[markandrus]

The same issue occurs in recent versions of Yarn. I discovered this while updating to 5.x. The problem can be worked around by adding the following to .yarnrc.yml in a Yarn project's root:

packageExtensions:
  "@fastify/type-provider-typebox@5.x":
    peerDependencies:
      "fastify": "5.x"

[idoperach]

Hey guys!

packageExtensions:
"@fastify/type-provider-typebox@5.x":
peerDependencies:
"fastify": "5.x"

Just updating this to the latest version of yarn, in my .yarnrc.yml this worked for me:

packageExtensions:
  '@fastify/type-provider-typebox@*':
    dependencies:
      'fastify': '*'
nodeLinker: pnp

any reason that fastify is not a dependency?

Would love to help with adding this if there is no reason not to add

[Nicolascrd]

Hello,
I have this issue as well with npm using npm workspaces.
The fastify app is one of the workspaces

Root package.json

{
  "private": true,
  "workspaces": [
    "fastify",
    "common",
    "..."
  ]
}

Workspace package.json

"dependencies": {
  "@fastify/type-provider-typebox": "^5.1.0",
  "@sinclair/typebox": "^0.34.33",
  "@myapp/common": "file: ../common",
  "fastify": "^5.3.0",
  ...
}

[paulius-valiunas]

@mcollina as you can see from the comment above, it's broken on npm too, not just pnpm or yarn.

any reason that fastify is not a dependency?

Would love to help with adding this if there is no reason not to add

@idoperach I guess you meant peerDependency? I've already tried: #165

I've been trying to prove that this has to be a peerDependency, but seems like the maintainers have aversion to peerDependencies in general. Perhaps our next step could be adding this package to the wall of shame?

[idoperach]

@paulius-valiunas Hey, yes I meant peerDependency, sorry

I saw the discussion at #165, I didn't understand the reasoning either as this is trusting more on the developer/team that uses the packages and may not fully know or understand what version of fastify is needed for each version of the plugin

I went to reads about on this subject to make sure that my understanding isn't personal and saw this official node blog post which explains exactly why this case is the definition of a peer dependency, it specifically mentions plugins, if we could talk to one of the maintiners, here or at #165 I would love to contribute

I think that we should add it to yarn only with the approval of the package maintainers as well since this will affect the usage among yarn users

if there is any way I could help to you or the maintainers on this I'll gladly do so

[paulius-valiunas]

@paulius-valiunas Hey, yes I meant peerDependency, sorry

I saw the discussion at #165, I didn't understand the reasoning either as this is trusting more on the developer/team that uses the packages and may not fully know or understand what version of fastify is needed for each version of the plugin

I went to reads about on this subject to make sure that my understanding isn't personal and saw this official node blog post which explains exactly why this case is the definition of a peer dependency, it specifically mentions plugins, if we could talk to one of the maintiners, here or at #165 I would love to contribute

I think that we should add it to yarn only with the approval of the package maintainers as well since this will affect the usage among yarn users

if there is any way I could help to you or the maintainers on this I'll gladly do so

I don't think we can expect any help or approval from the maintainers on this. They clearly have this religious hatred towards peerDependencies based on their poor past attempts to use them. I tried to reason with them, but I gave up.

The reason the yarn database exists in the first place is because of uncooperative maintainers, which seems to be exactly what we're facing here. If you look through the existing extensions in the yarn repo, you'll see that the ones with "*" version (for example http-link-dataloader@*) all have linked PRs that have been ignored for years or closed without merging.