Release 3.1.0 broke type inference on fastify route handler request parameter

[g0di]

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.15.0

Plugin version

3.1.0

Node.js version

16.19.1

Operating system

macOS

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

Monterey 12.6.5

Description

Hi,

Just updated plugin to version 3.1.0 recently and it looks like I lost types inference on the fastify routes handler request object. I rollbacked to 3.0.0 which is working fine. The following screenshot is showing that I no longer get types inference on the params object of the fastify request despite schema definition being provided and Typebox type provider being used.

Thank you for your help ;)

Steps to Reproduce

import { TypeBoxTypeProvider } from '@fastify/type-provider-typebox';
import { Type } from '@sinclair/typebox';
import fastify from 'fastify';

fastify()
  .withTypeProvider<TypeBoxTypeProvider>()
  .get('/', {
    schema: {
      params: Type.Object({
        foo: Type.String()
      })
    },
    handler(req, rep) {
      console.log(req.params.foo);
      rep.send();
    }
  });

Expected Behavior

• In the previous example, req.params.foo should be typed as a string.
• Using strict flag with typescript, I should not get the following error:

'req.params' is of type 'unknown'.ts(18046)

[SeanReece]

I think this could be a Typebox version compatibility issue. I ran into something similar, type-provider-typebox now exports @sinclair/typebox directly so you should use that export. The docs have been updated to reflect the new usage.

import { TypeBoxTypeProvider, Type } from '@fastify/type-provider-typebox';
// Do not import @sinclair/typebox directly
import fastify from 'fastify';

fastify()
  .withTypeProvider<TypeBoxTypeProvider>()
  .get('/', {
    schema: {
      params: Type.Object({
        foo: Type.String()
      })
    },
    handler(req, rep) {
      console.log(req.params.foo);
      rep.send();
    }
  });

[digitalmio]

I'm experiencing the same problem - changed import to type-provider-typebox but it didn't help.

[semoal]

@sinclairzx81 any guidance here? Experiencing this upgrading from *27.8 to 28.5

[sinclairzx81]

@semoal Hi!

In 3.0, TypeBox was taken as a direct dependency on the provider (where as previously it was a peerDependency). If manually upgrading to TypeBox 0.28.x (or versions higher than the dependency used by the provider) this may be the cause type inference problems as TypeScript may be observing both installed versions of TypeBox (leading to possible type inference ambiguities).

There's a couple of options I can think of to resolve this.

A) Upgrade the provider to use TypeBox 0.28.x
B) Retain re-export of Type.* but revert to peerDependency,

I think option B might be the most flexible option for sourcing the most recent TB revisions.

@mcollina @RafaelGSS Any thoughts on this?

[seia-soto]

Hopefully, seems like the patches in progress.

Just sharing my use: I always write a dedicated import to TypeBox from the actual TypeBox package (@sinclair/typebox) instead of Type exported from @fastify/type-provider-typebox. It's because I want to match the import with other script files that uses TypeSystem.Format. For later releases, I also suggest that exporting the TypeSystem and other ecosystem in TypeBox is preferred.

Also, the library should be peer dependency in my case.

[nadhifikbarw]

Since I personally prefer reverting back to peerDependency approach i've opened PR #78 if we do agree to pick this alternative. If we pick other alternatives, PR can be closed.

For others looking for temporary solution, in the meantime, you can keep using 3.1.0 by version pinning your @sinclair/typebox dependency to 0.27.8 (but I also recommend also performing exact version pinning to 3.1.0 in case fix is being rolled out later for your project stability).

[RafaelGSS]

I'd go with option B. However, I'm not sure it will solve all the edge cases.

[erfanium]

+1
I suggest move it back to peerDependecies
more detail here

[nadhifikbarw]

@mcollina okay to release 3.3.0 and close this?

[mcollina]

yes

[mcollina]

@nadhifikbarw I'm lost in what should be in v3.3.0, could you clarify?

[mcollina]

I think this issue was solved in v3.2.0.