feat(ngcc): support __spreadArray helper as used by TypeScript 4.2#41201
feat(ngcc): support __spreadArray helper as used by TypeScript 4.2#41201JoostK wants to merge 3 commits intoangular:masterfrom
__spreadArray helper as used by TypeScript 4.2#41201Conversation
In TypeScript 4.2 the `__spread` and `__spreadArrays` helpers were both replaced by the new helper function `__spreadArray` in microsoft/TypeScript#41523. These helpers may be used in downleveled JavaScript bundles that ngcc has to process, so ngcc has the ability to statically detect these helpers and provide evaluation logic for them. Because Angular is adopting support for TypeScript 4.2 it becomes possible for libraries to be compiled by TypeScript 4.2 and thus ngcc has to add support for the `__spreadArray` helper. The deprecated `__spread` and `__spreadArrays` helpers are not affected by this change. Closes angular#40394
JoostK
added
feature
petebacondarwin
left a comment
petebacondarwin
left a comment
There was a problem hiding this comment.
Ahead of the game @JoostK
| return DynamicValue.fromInvalidExpressionType(node, from); | ||
| } | ||
|
|
||
| return from.concat(to); |
There was a problem hiding this comment.
Oops, I spoke too soon. This should be
| return from.concat(to); | |
| return to.concat(from); |
There was a problem hiding this comment.
That is entirely correct! I didn't notice as the evaluator spec are part of ngtsc/partial_evaluator and I only ran the ngcc test targets.
crisbeto
left a comment
crisbeto
left a comment
There was a problem hiding this comment.
I don't have a lot of context here, but do we also have to account for the __read helper? It seems to be used together with __spreadArray. See https://github.com/angular/angular/pull/41158/files#diff-e5db61a4fea6171227d1b25300c43bc2f33613fefb1d98bb37ad746264c3661bR3006
Very good point, yes we do! The |
This commit complements the support for the `__spreadArray` helper that was added in microsoft/TypeScript#41523. The prior helpers `__spread` and `__spreadArrays` used the `__read` helper internally, but the helper is now emitted as an argument to `__spreadArray` so ngcc now needs to support evaluating it statically. The real implementation of `__read` reads an iterable into an array, but for ngcc's static evaluation support it is sufficient to only deal with arrays as is. Additionally, the optional `n` parameter is not supported as that is only emitted for array destructuring syntax, which ngcc does not have to support.
JoostK
added
action: review
Is it not possible for a developer to use an iterator in a spread expression? |
petebacondarwin
left a comment
petebacondarwin
left a comment
There was a problem hiding this comment.
I would like to know why the implementation of __read doesn't require iterator support. But that could be added on as a subsequent PR if it is found to be necessary.
AFAIK this would not be statically evaluable, i.e. instantiating a |
JoostK
added
action: merge
AndrewKushnir
removed
the
action: presubmit
This commit complements the support for the `__spreadArray` helper that was added in microsoft/TypeScript#41523. The prior helpers `__spread` and `__spreadArrays` used the `__read` helper internally, but the helper is now emitted as an argument to `__spreadArray` so ngcc now needs to support evaluating it statically. The real implementation of `__read` reads an iterable into an array, but for ngcc's static evaluation support it is sufficient to only deal with arrays as is. Additionally, the optional `n` parameter is not supported as that is only emitted for array destructuring syntax, which ngcc does not have to support. PR Close #41201
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
4 participants
In TypeScript 4.2 the
__spreadand__spreadArrayshelpers were bothreplaced by the new helper function
__spreadArrayinmicrosoft/TypeScript#41523. These helpers may be used in downleveled
JavaScript bundles that ngcc has to process, so ngcc has the ability to
statically detect these helpers and provide evaluation logic for them.
Because Angular is adopting support for TypeScript 4.2 it becomes
possible for libraries to be compiled by TypeScript 4.2 and thus ngcc
has to add support for the
__spreadArrayhelper. The deprecated__spreadand__spreadArrayshelpers are not affected by this change.Closes #40394