Mark deep indexed access comparisons as expanding#33144
Conversation
|
@typescript-bot test this |
|
Heya @weswigham, I've started to run the extended test suite on this PR at 7861cf4. You can monitor the build here. It should now contribute to this PR's status checks. |
|
Heya @weswigham, I've started to run the parallelized community code test suite on this PR at 7861cf4. You can monitor the build here. It should now contribute to this PR's status checks. |
|
Heya @weswigham, I've started to run the parallelized Definitely Typed test suite on this PR at 7861cf4. You can monitor the build here. It should now contribute to this PR's status checks. |
|
cc @DanielRosenwasser since the referenced issue is reported as a regression in the 3.6 release~ |
|
The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master. |
|
User baselines are just today's as yet uncaptured/accepted update (just changes in upstream projects), so are clean~ |
|
@typescript-bot pack this |
|
Heya @weswigham, I've started to run the tarball bundle task on this PR at 7861cf4. You can monitor the build here. It should now contribute to this PR's status checks. |
|
Hey @weswigham, I've packed this into an installable tgz. You can install it for testing by referencing it in your and then running |
|
I wonder if this would also fix:
Edit: @weswigham I can confirm that this fixes my comment in this older issue: #29112 (comment) |
|
@weswigham The insiders build fixes the issue I was having as well with
and
For now I've had to rollback to 3.5 as my choice is 3.6 and removing @types/lodash or 3.5 and have proper types for lodash. |
7861cf4 to
67fbdfa
Compare
|
@typescript-bot cherry-pick this into release-3.6 |
|
Hey @weswigham, I've opened #33249 for you. |
TypeScript 3.6 cannot be updated because of a current bug with FindConditions<?>. typeorm/typeorm#4470 typeorm/typeorm#4662 microsoft/TypeScript#33144
Fixes #33132
Just as
isDeeplyNestedTypemarks objects which re-nest >5 times as maybe infinitely expanding, it now also marks indexed accesses which nest >5 times in the same way. Since a deeply nested indexed access is essentially the dual of a deeply nested object type (or at least you'd need a deeply nested object to satisfy the indexing operations!), this makes sense to me.