You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Expected behavior:
I would expect this to compile correctly.
Actual behavior:
There are two compile errors on assignment.
Type '({ foo: number; bar: number; baz?: undefined; } | { baz: string; foo?: undefined; bar?: undefined; })[]' is missing the following properties from type '[{ foo: number; bar: number; }, { baz: string; }]': 0, 1
and
Type '(string | number)[]' is missing the following properties from type '[number, string]': 0, 1
Playground Link:
Because this relies on the resolveJsonModule flag, I cannot reproduce this in a typescript playground. Instead, I have created this small repository which demonstrates the failed compilation. https://github.com/jcgsville/typescript-json-bug-repro
Related Issues:
Here is a similar issue, but doesn't address how it infers the type of arrays. #27913
Discussion:
I could see an argument that this is intended behavior and a known limitation of the degree of sophistication of a type inferred from JSON. However, I'd expect that the JSON module resolution would resolve it to a more strict type, and the user of the module could loosen it on assignment/usage if they want.
For example, if the type of schema1 was resolved to be [ { foo: number; bar: number }, { baz: string } ], then assigning it to a looser type would succeed. See the following example
There are many use cases for heterogeneous arrays, but I encountered this when trying to represent anyOf in JSON Schema in a JSON module in a typescript project, which is currently impossible to do with @types/json-schema without an as unknown cast.
The text was updated successfully, but these errors were encountered:
This is the intentional behavior because the "not specific enough" failure mode is fairly understandable, whereas the alternative where you get some enormous type full of literals because you imported a large JSON file is just unworkable. For example, I have seen projects where people import a 2 MB JSON file for type information -- turning that into the equivalent of an as const would tank performance and yield types you simply couldn't fit on any screen.
That's a good point @RyanCavanaugh, and it's one I hadn't considered.
Do you think that there could be a future where TS could support both? Maybe you could represent the desire for Tuples (and maybe const objects as well?) with something like this
@jcgsville I was going to propose the same as const qualifier on an import. But if you're going to make it as anything, you may as well specify the type you want:
TypeScript Version: 3.9.0-dev.20200407
Search Terms:
json module array type resolveJsonModule
Code
schema1.json
schema2.json
Expected behavior:
I would expect this to compile correctly.
Actual behavior:
There are two compile errors on assignment.
and
Playground Link:
Because this relies on the resolveJsonModule flag, I cannot reproduce this in a typescript playground. Instead, I have created this small repository which demonstrates the failed compilation.
https://github.com/jcgsville/typescript-json-bug-repro
Related Issues:
Here is a similar issue, but doesn't address how it infers the type of arrays.
#27913
Discussion:
I could see an argument that this is intended behavior and a known limitation of the degree of sophistication of a type inferred from JSON. However, I'd expect that the JSON module resolution would resolve it to a more strict type, and the user of the module could loosen it on assignment/usage if they want.
For example, if the type of schema1 was resolved to be
[ { foo: number; bar: number }, { baz: string } ]
, then assigning it to a looser type would succeed. See the following exampleThere are many use cases for heterogeneous arrays, but I encountered this when trying to represent anyOf in JSON Schema in a JSON module in a typescript project, which is currently impossible to do with @types/json-schema without an
as unknown
cast.The text was updated successfully, but these errors were encountered: