Issues with Fastify + TypeBox

[hrishikesh-k]

Hello!

I'm trying to use Fastify with TypeBox and currently running into 2 issues:

1. Unable to set Response type for multiple status codes

Consider the following setup:

// api.ts
import awsLambdaFastify from '@fastify/aws-lambda'
import fastify from 'fastify'
import fastifyCookie from '@fastify/cookie'
import routeSignup from '~/server/routes/signup.ts'
import type {TypeBoxTypeProvider} from '@fastify/type-provider-typebox'
const api = fastify().withTypeProvider<TypeBoxTypeProvider>()
api.register(fastifyCookie)
api.register((app, _, done) => {
  routeSignup(app)
  done()
}, {
  prefix: '/api/'
})
export const handler = awsLambdaFastify(api)

// routes/signup.ts
import {type FastifyTypebox, RouteSignupReqBody, RouteSignupRes, type TRouteSignupReqBody, type TRouteSignupRes} from '~/types/global.ts'
export default function (api : FastifyTypebox) {
  api.post<{
    Body : TRouteSignupReqBody
    Reply : TRouteSignupRes
  }>('/signup', {
    schema: {
      body: RouteSignupReqBody,
      response: {
        200: RouteSignupRes
        400: {
          msg: 'string'
        }
      }
    }
  }, (req, res) => {
    if (req.body.email === 'already in use') {
      res.status(400).send({
        msg: 'email already in use'
      })
    } else {
      res.send({
        email: 'foo@bar.com',
        id: '123'
        name: 'foo bar'
      })
    }
  }
}

// types.ts
export type FastifyTypebox = FastifyInstance<RawServerDefault, RawRequestDefaultExpression, RawReplyDefaultExpression, FastifyBaseLogger, TypeBoxTypeProvider>
export const RouteSignupReqBody = Type.Object({
  email: Type.String({
    format: 'email'
  }),
  name: Type.String()
})
export const RouteSignupRes = Type.Object({
  email: Type.String({
    format: 'email'
  }),
  id: Type.String(),
  name: Type.String()
})
export type TRouteSignupRes = Static<typeof RouteSignupRes>
export type TRouteSignupReqBody = Static<typeof RouteSignupReqBody>

This gives me an error saying:

Object literal may only specify known properties, and msg does not exist in type {email: string, id: string, name: string}

If the schema allows setting a different schema for each status code, I thought the type provider would also allow the same, but that doesn't seem possible.

2. Unable to use plugins:

In the above example, I am trying to use fastifyCookie. As you can see, I have registered the plugin, but in my signup.ts file, I'm unable to use res.cookie(). What am I doing wrong?

[mcollina]

Could you put assemble a repository for ease of reproduction?

@sinclairzx81 could you take a look?

[hrishikesh-k]

Sure, here's a reproduction: reproduction.zip

While preparing it, I got the .cookie() thing working, I guess, but the first problem still remains:

[mcollina]

@flakey5 would you like to take a look as well?

[sinclairzx81]

@hrishikesh-k Hi. I'm not familiar with @fastify/cookie plugin, however I did find a few issues with the signup.ts module. I've updated your repro script pasted these updates below.

The main two issues I saw were:

1. Using explicit generics on the route which were overriding the TypeProvider on api
2. No 400 status code type (for { msg: ... } on either generics or schema)

I've added comments where applicable.

import type { FastifyTypebox } from '~/types/global.ts'
import { RouteSignupReqBody, RouteSignupRes } from '~/types/global.ts' // No need to import TRouteSignupReqBody, TRouteSignupRes
import { Type } from '@sinclair/typebox'

export default function (api: FastifyTypebox) {
  api.post('/signup', {              // <-- Remove generic parameters on route. Note that explicitly specifying 
    schema: {                        //     generics will override the TypeProvider. We can leave them
      body: RouteSignupReqBody,      //     out here.
      response: {
        200: RouteSignupRes,
        400: Type.Object({           // <-- Add a status 400 response type. 
          msg: Type.String()
        })
      }
    }
  }, (req, res) => {
    if (req.body.email === 'foo') {
      res.status(400).send({       // <-- this is fixed
        msg: 'email already in use'
      })
    } else {
      res.cookie('token', '123').send({ // You will need to refer to the documentation for res.cookie(), I am not
        email: 'foo@bar.com',           // familiar with this plugin.
        id: '123',
        name: 'hello!'
      })
    }
  })
}

As for the res.cookie(...) call, you may need to ping one of the devs that work on this package. However if you replace the res.cookie({ token: 123 }).send({...}) call with res.status(200).send({...}) call, the types line up correctly with no errors. This should narrow the scope of this issue to the correct configuration of the @fastify/cookie package.

Hope this helps lead to a solution!
Cheers!
S

[hrishikesh-k]

Thank you so much for this! I can see this indeed works, but this won't let me use type-checking with TypeScript, would it? I was simply referring to: https://fastify.dev/docs/latest/Reference/TypeScript/#typebox which shows the usage of generics:

fastify.post<{ Body: UserType, Reply: UserType }>

Is that not the correct way to specify types for the request? My use-case is to build a strongly-typed API Client for my frontend, so I can use TypeScript to sync the request and response payloads along with query params, headers, etc. With the approach you suggested (which is also what I have been using in other projects), I can get Fastify to validate the request fine, but I can't use static type-checking to know about the errors during the build stage or during development in my IDE.

[sinclairzx81]

@hrishikesh-k Heya

Thank you so much for this! I can see this indeed works, but this won't let me use type-checking with TypeScript, would it? I was simply referring to: https://fastify.dev/docs/latest/Reference/TypeScript/#typebox which shows the usage of generics:

Type Providers are able to automatically infer the type, so you don't need to duplicate generics + schema definition (you only need to configure the schema definition for the route). They also offer the same level of type safety as generics. Type Providers are not configured by default (you have to enable them). Documentation on them can be found at the link below

https://fastify.dev/docs/latest/Reference/Type-Providers/

[hrishikesh-k]

Inference works, but it still allows me to mistakenly add extra properties which generics don't. For example, my signup.ts is now:

import type {FastifyTypebox} from '~/types/global.ts'
import {Type} from '@sinclair/typebox'
export default function (api : FastifyTypebox) {
  api.post('/signup', {
    schema: {
      body: Type.Object({
        email: Type.String()
      }),
      response: {
        200: Type.Object({
          email: Type.String(),
          name: Type.String()
        }, {
          additionalProperties: false
        }),
        400: Type.Object({

        }, {
          additionalProperties: false
        })
      }
    }
  }, (req, res) => {
    if (req.body.email === 'foo') {
      res.status(400).send({
        msg: 'email already in use'
      })
    } else {
      res.send({
        email: 'foo@bar.com',
        id: '123',
        name: 'hello!'
      })
    }
  })
}

As you can see, I have now added additionalProperties: false, but TypeScript compiler still doesn't complain about msg being extra in the 400 and id being extra in the 200 response. Let me know if this is not an intended use-case, in which case this discussion becomes moot, but if it's me holding it wrong, or using something incorrectly, please point it out.

I believe I can turn on response validation in Fastify to catch these errors, but I was hoping to catch these errors early in the IDE.

Thanks for the help so far!

[sinclairzx81]

As you can see, I have now added additionalProperties: false, but TypeScript compiler still doesn't complain about msg being extra in the 400 and id being extra in the 200 response. Let me know if this is not an intended use-case, in which case this discussion becomes moot, but if it's me holding it wrong, or using something incorrectly, please point it out.

Yes, this is normal. TypeBox (as well as TypeScript depending on usage) won't complain about additional properties. It will only statically assert the properties it knows about (the ones you define), not the ones it doesn't know about. This is in support of structural (polymorphic) assignment. Consider.

type T = { a: number, b: number }

const A = { a: 1, b: 2, c: 3 } // c is additional

const B: T = A // A is structurally assignable to B

However TS will assert for the following

type T = { a: number, b: number }

const A: T = { a: 1, b: 2, c: 3 } // error c is additional

TypeBox can only reasonably adopt the former, not the latter (with the latter tied more to type assertion patterns use by the developer). As such, the additionalProperties constraint does not contribute to type inference in TypeBox (it relates to Json Schema only)