Type error when using Type.Number() in response type

[colatkinson]

Minimal repro: https://gist.github.com/colatkinson/57a1a4ba78ee2d10be29ae49df470fc1#file-index-ts

This is a lightly-modified version of the start-server.ts example -- the major difference being that the type of pong is changed from Type.Boolean() to Type.Number().

Note also that the package-lock.json file is also included in the gist if you're curious about the exact package versions used. This was tested with node 18.16.1, though it has been observed on 16.X as well.

Running tsc -p . (or npm run build) will fail with the following error:

$ npm run build

> [email protected] build
> tsc -p .

index.ts(32,11): error TS2322: Type 'TObject<{ pong: TNumber; }> & TaggedSchema' is not assignable to type 'SchemaObject'.
  Types of property 'properties' are incompatible.
    Type '{ pong: TNumber; }' is not assignable to type '{ [propertyName: string]: SchemaObject | ReferenceObject; }'.
      Property 'pong' is incompatible with index signature.
        Type 'TNumber' is not assignable to type 'SchemaObject | ReferenceObject'.
          Property '$ref' is missing in type 'TNumber' but required in type 'ReferenceObject'.

The error is quite misleading, though. The actual issue seems to be conflicting definitions of the exclusiveMaximum and exclusiveMinimum fields.

1. OpenAPI 3.1 is based on JSON Schema Specification Draft 2020-12, which specifies exclusiveMaximum et al as numbers.
2. Typebox targets JSON schema draft 6 which also has them as numbers.
3. openapi3-ts, which fastify-openapi3 uses under the hood, seems to have both the number and boolean variants available in the current version.
4. However, fastify-openapi3 is using a version of openapi3-ts that's two major versions behind. In this version, exclusiveMaximum is specified as a boolean.

As a result of this, the typebox-generated TNumber (which has exclusiveMaximum as a number) cannot be assigned to the outdated SchemaObject definition, which causes tsc to go off on a tangent trying to check its compatibility to ReferenceObject.

Note that our current workaround is included as well, though this is not desirable long-term because it gives the typebox objects the incorrect types (i.e. boolean) for compatibility with this library.

I suspect upgrading openapi3-ts will fix the issue, but I don't know how involved a process that would be.

Please let me know if anything is unclear, or if I can do anything further to help resolve the issue.

[colatkinson]

Also possibly worth mentioning: I did try using typebox==0.28.9 (the version in this repo's package.json), but the error is present with that version as well.

[eropple]

Hey - I never got a notification for this issue, I'm awfully sorry about that. I'm looking at this library for a new project at the moment and I'll give this a squint.

[eropple]

So openapi3-ts has completely changed their API, twice, and done so in an undocumented manner. Like, I'm doing an "upgrade all the things" renovation, and I literally can't figure out how they changed it (and don't have time to source-dive it). For a library with something like 500K installs...that's kind of terrifying!

I would like to get away from it entirely because that's scary, but I have been a bit out of that side of the universe for a while, so I'd love your thoughts, @colatkinson.