-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for intrinsic string manipulation on TString #690
Comments
@quentinverlhac Hi, Thanks for the suggestion, I think this is a good idea. Currently intrinsic string manipulation types are only supported for remapping finite literal/template literal values, with the intrinsic applying an immediate remap of the type. const T = Type.Uppercase(Type.Literal('hello')) // T: TLiteral<'HELLO'> Where above the return value is evaluated immediately to be const T = Type.Object({
value: Type.Uppercase(Type.String()) // only allow strings that are uppercase
}) In which case the schema would be I will do a review of what would be required to make it work once 0.32.0 is published. Unfortunately, I don't expect this functionality to land soon (as I expect implementing this correctly would involve updating a quite a few existing types to ensure they map correctly), but will try pick it up early to mid next year. Thanks for the suggestion! |
Hi @sinclairzx81, |
Hello,
This issue is reporting what seems to me an inconsistency with TypeScript behaviour.
Since this pull request, TypeScript allows a type to represent all the strings that are
Uppercase
,Lowercase
,Capitalize
, orUncapitalize
.These types are
Uppercase<string>
,Lowercase<string>
Capitalize<string>
andUncapitalize<string>
respectively.However it seems that typebox doesn't support this feature.
Applying an intrinsic type on a string type gives a
TString
type, which is then inferred intostring
type instead of following the TypeScript behaviour.For example:
But in TypeScript:
Would it be possible to support this feature when inferring the static type of a schema?
Maybe there is a good reason not to support this feature and I missed it, apologies if this is the case.
Thank you for supporting this package!
The text was updated successfully, but these errors were encountered: