fix(migrations): do not migrate next calls in template if not an EventEmitter#58631
fix(migrations): do not migrate next calls in template if not an EventEmitter#58631cexbrayat wants to merge 1 commit intoangular:mainfrom
Conversation
556c16c to
e749d74
Compare
e749d74 to
7e2780b
Compare
There was a problem hiding this comment.
I'm thinking, ideally, we'd filter in the global meta stage, as technically, the call expression could refer to an output from a whole different compilation unit (e.g. tsconfig.json).- probably needs some larger refactoring though.
There was a problem hiding this comment.
Agreed, this was exactly my observation when scanning through the PR.
The logic needs updating since today we just pile up refactoring for a given property, sometimes assuming that it is an output
pkozlowski-opensource
left a comment
There was a problem hiding this comment.
As discussed in the PR comments this fix can be insufficient in some more complex cases. Getting complete fix would require refactoring that will not land before v19.
Given this I think that we should merge it and work on other fixes as a follow-up.
devversion
left a comment
There was a problem hiding this comment.
LGTM, agreed with Pawel, but maybe have a TODO?
…tEmitter Fixes angular#58630 ```html <button (click)="someSubject.next()">Click</button> ``` was migrated to an `.emit` call, even if `someSubject` was not an `EventEmitter`. The issue was the same in host listeners.
7e2780b to
345c956
Compare
|
@devversion I added a TODO based on your comment 👍 |
|
This PR was merged into the repository by commit 2eb4afe. The changes were merged into the following branches: main, 19.0.x |
|
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. |
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Fixes #58630
was migrated to an
.emitcall, even ifsomeSubjectwas not anEventEmitter.What is the new behavior?
This is no longer the case
Does this PR introduce a breaking change?
Other information