Make applying DeepReadonly idempotent #107
Conversation
|
Actually, it turns out that the issue I pointed to above is a real problem, those are two different types according to typescript... Any ideas on how to detect that we've already applied |
aaronjensen
force-pushed
the
recursive-deep-readonly
branch
from
99b0ef7
to
ed74ea0
Compare
|
Maybe this will help (More) Recursive Type Aliases |
|
Okay, I've pushed up a commit with a new solution that uses a symbol tag to skip applying DeepReadonly again. I'm not sure how you feel about privateish symbol tags, but this is the only way I know how to do something like this. |
|
@steida I think that'll help with the ultimate definition so we don't have to create separate interfaces to enable recursion, but I'm not sure it helps with this directly, but maybe I'm missing something. |
aaronjensen
changed the title
|
Unfortunately, the tagging taints Records, which makes things like |
aaronjensen
force-pushed
the
recursive-deep-readonly
branch
from
1b9d27e
to
24d4555
Compare
|
Addressed feedback in 9fa8988, I think there may be a conflict between the dts snap and prettier now, however—not sure how you want to resolve that. I could split up the primitive test so prettier doesn't want to reformat. |
|
Also, let me know if you'd like me to squash the commits or if you just plan on doing it w/ GitHub. Thanks! |
|
|
||
| // @dts-jest:pass:snap -> _DeepReadonlyObject<{ first: { second: { name: string; }; }; }> | ||
| testType<DeepReadonly<DeepReadonly<NestedProps>>>(); | ||
| // @dts-jest:pass:snap -> _DeepReadonlyObject<{ first: { second: { name: string; }[]; }; }> | ||
| testType<DeepReadonly<DeepReadonly<NestedArrayProps>>>(); | ||
|
|
||
| // @dts-jest:pass:snap -> string | number | bigint | boolean | symbol | null | undefined | ||
| testType< | ||
| DeepReadonly<string | null | undefined | boolean | number | bigint | symbol> | ||
| >(); |
| : T extends _DeepReadonlyArray<infer U> | ||
| ? _DeepReadonlyArray<U> | ||
| : T extends _DeepReadonlyObject<infer V> | ||
| ? _DeepReadonlyObject<V> |
fixes #106
This isn't as clean as I'd like—ideally a recursive application would have no impact. For example, the newly added test would match as if it weren't applied twice:
Above, the
_DeepReadonlyObjectis superfluous and isn't there if applied only once.Description
Related issues:
Checklist
For bugfixes:
For new features:
dts-jest