-
Notifications
You must be signed in to change notification settings - Fork 408
Excessively large type for maxItems
#372
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
Comments
We also have this problem for even smalller arrays but with more complex objects. Also, the generated type cannot be easily named/referenced and its items become distinct types. I'd prefer to just have the generated type be simple array and leave out the length completely, otherwise you get into the dependant type territory too much which just brings unnecessary amounts of coplexity, while it's not needed for most cases, because the length is runtime value anyway. |
While it's not documented in the cli options, you can actually disable the min/maxlength check with the |
That's good to know, thanks ;) |
|
Fixed in a89ffe1 |
1 similar comment
Fixed in a89ffe1 |
Given a property such as:
The generated type will be:
Given a
maxItems
of 1000, the type definition becomes truly massive, and even fails to be generated in some cases.Given a
TupleOf
type (from here) we could shrink this down quite a bit:This will still generate 1000 tuples in the union, but each tuple will only contain the parameter type once, rather than N times.
The text was updated successfully, but these errors were encountered: