Comments (3)
@sdeprez Hi!
But maybe we can at least improve the type {} for Type.object({}), which is arguably wrong because it allows any non-null values? It could use object for instance so at least it would only allow real objects, and not other primitive values, which is consistent with the generated json schema.
Yeah, let me have a think about this. I think if making changes to TObject inference, I'd want to factor the additionalProperties in that inference. Similarly based on #889, I think there is also a case to consider factoring unevaluatedProperties in inference too (where this issue highlights some of the cross over between inference, types and runtime assertion logic).
Ill add a consideration tag to this issue and take a technical deep dive on it next time I get to sit down with the code. However given the complexity and general changes required, I wouldn't expect this functionality to land until the next minor revision (scheduled later on this year), but will see how things go.
Will keep you posted!
S
from typebox.
@sdeprez Hi,
In that case, the type of T is {}, which in Typescript actually validates every non-null values, so the following assignments are all valid:
This is somewhat intentional (and partially historical) but mostly a consequence of TObject types not factoring additionalProperties constraints in inference (although the permissible number and string assignments are unfortunate). I think to provide better inference here, TObject should infer as one of the following depending on the whether additionalProperties has been specified.
For example, consider the following (where an empty object without constraints is permissible of additional properties)
const T = Type.Object({}) // type T = Record<PropertyKey, unknown>
const S = Type.Object({}, { additionalProperties: false }) // type T = Record<PropertyKey, never>
const U = Type.Object({}, { additionalProperties: Type.Number() }) // type T = Record<PropertyKey, number>
Unfortunately, this leads to some fairly awkward scenarios.
const T = Type.Object({
x: Type.String(),
y: Type.String(),
z: Type.String(),
}, {
additionalProperties: Type.Number()
})
type T = Record<PropertyKey, number> & {
x: string,
y: string,
z: string
}
const a: T = { // error unassignable: property values of string
x: '1', // are not number
y: '2',
z: '3'
}
Do you have any thoughts or suggestions regarding the appropriate inference when factoring the above additional Property constraints? Open to discussion on this.
Cheers
S
from typebox.
Thanks for your detailed response!
I agree that if we factor additionalProperties
, it gets more complex 🤔 . But maybe we can at least improve the type {}
for Type.object({})
, which is arguably wrong because it allows any non-null values? It could use object
for instance so at least it would only allow real objects, and not other primitive values, which is consistent with the generated json schema.
For the record, I'm using this great library ;) typebox inside fastify
and I'm using Static
to extract types from my serializers. I tripped over this issue here when I wondered when one route handler that was returning a boolean did not make the typecheck fail. So I would be happy with an object
type instead, and it wouldn't check for additional properties but that's consistent with the other types from what I understand, and unwanted properties would be removed by the serializer anyway.
from typebox.
Related Issues (20)
- Types for both CJS and ESM cause ambiguity and prevent correct type resolution. HOT 8
- unique id for schemas generated with Type.Object() HOT 6
- Custom paths for custom validation errors HOT 2
- Composite Union type does not work HOT 3
- Type.Recursive does not work with Type.Transform for StaticDecode HOT 1
- Issue regarding nested objects when using Value.Default HOT 5
- Enum type inferred as never when using Type.Mapped() HOT 2
- Should `IsValueType` guard consider `Date`? HOT 1
- ESNext target HOT 3
- Trying to do codegen from Drizzle schemas HOT 1
- Make `default` and `examples` schema options properties type-safe HOT 2
- Indicate which files don't have "sideEffects" in package.json for improved tree shaking HOT 3
- Type.String().Optional() is accepted on ts-hint / ts-lint, and even build successfully; but of course, "Optional()" does not exists HOT 2
- Dynamic Template Literals can't be Mapped HOT 2
- How should TypeBox types be used with TS type predicates? HOT 2
- TypeCompiler.Compile incorrectly parsing `Record<any, any>` HOT 7
- Error when using Composite with Ref (Unable to dereference schema with $id 'undefined') HOT 3
- Transform type keys in Record HOT 2
- Is it possible to add support to the Type.String additional properties for the enum keyword HOT 2
- Support for async validations? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from typebox.