Closed StanleySathler closed 1 year ago
@StanleySathler Hi, thanks :)
This should still be working as before. However, there has been some changes to remove the Format<string>
generic argument from the TString
. This was removed inline with the new Template Literals (and possibly to make some head way to unifying literals strings with TString in some capacity). The decision to remove was due to the TString<format>
having no TypeScript equivalent.
// Before
const T1: TString<string> = Type.String()
const T2: TString<'email'> = Type.String({ format: 'email' })
// After
const T3: TString = Type.String()
const T4: TString = Type.String({ format: 'email' })
This change is only implemented at the type level, no runtime changes were implicated.
The following should still work as before (note the given function that is constrained to type TSchema
)
import { Type, Static, TSchema } from '@sinclair/typebox'
export const Vector = <T extends TSchema>(schema: T) => Type.Object({
x: schema,
y: schema,
z: schema
})
const A = Type.String()
const B = Vector(Type.String())
const C = Vector(Type.Number())
const D = Vector(Type.Boolean())
type A = Static<typeof A>
type B = Static<typeof B>
type C = Static<typeof C>
type D = Static<typeof D>
One thing that might be causing an issue is having multiple versions of TypeBox installed. As the definition of TString
would vary from old to new versions, this might be causing type inference problems. Are you able to check?
@StanleySathler Hi,
Might close off this issue for now as you should still be able to pass Type.String()
as TSchema
(as per example link). If you are still having problems though, it might be worth checking you don't have multiple versions of TypeBox installed (as these are known to cause inference issues in some cases)
In general though (and something to be mindful of if upgrading) there has been quite a few breaking changes on 0.26.0
, 0.27.0
and 0.28.0
as these minor revisions have introduced a several new composable types (Extends
, Extract
, Exclude
, Composite
, TemplateLiteral
, Index
, Rest
), as well as changes to existing types to better align with TypeScript (with specific note to TIntersect
representation change on 0.26.0 which was a big breaking change). Had TypeBox been 1.0, these would be considered major revisions.
Breaking changes are documented with new features to the best of my ability on the changelog. Relevant links below
https://github.com/sinclairzx81/typebox/blob/master/changelog/0.26.0.md https://github.com/sinclairzx81/typebox/blob/master/changelog/0.27.0.md https://github.com/sinclairzx81/typebox/blob/master/changelog/0.28.0.md
These three revisions in particular have been quite dramatic in their scope, as each has involved fairly sweeping changes to TypeBox's inference infrastructure and runtime compositing system. Attempts are always made to avoid breaking changes, but of the breaking change that are there, they are in equal part carefully considered, intentional and unfortunate.
Currently the 0.28.0 is the last significant revision for a while (at least on the type inference and compositing side). Most updates going in for the next few months will be any bug fixes to the current setup, and further stabilization of these three revisions. Most of what's there should be fairly stable, but there's been a bit of churn around TComposite
recently. Everything else should be mostly in check.
Hope this helps bring some insight! Will close off for now. Cheers S
Thank you so much for the amazing work with Typebox. 🙌
I noticed that some of the recent patch versions had breaking changes. One example was that, after upgrading, I couldn't pass
Type.String()
to a function that expectedTSchema
, and that has worked in the past.Is this intentional?