build: ngOnChanges property access rule not working - #21075
Merged
Conversation
Member
Author
|
Blocked on #21074. |
crisbeto
force-pushed
the
property-access-rule-failures
branch
from
November 18, 2020 14:44
a5e042b to
66b6934
Compare
Member
Author
|
No longer blocked. |
Contributor
|
@crisbeto Can you force push to try and force CI to run? Something weird happened here and it's not running. |
Follow-up to angular#21074. We have a lint rule that flags property accesses like `changes.foo` where `changes` is a `SimpleChanges` object, because they'll break under Closure compiler. The rule depends on the TS type checker to identify the objects, but it seems like somewhere along the way, tslint changed how they construct the `Program` which removed the necessary type information. These changes add a less complicated fallback which looks at whether the name of the receiver of a property access is the same as the name of the first method parameter.
crisbeto
force-pushed
the
property-access-rule-failures
branch
from
November 20, 2020 19:42
66b6934 to
6348b6c
Compare
Member
Author
|
Done. Also rebased. |
annieyw
pushed a commit
that referenced
this pull request
Nov 24, 2020
Follow-up to #21074. We have a lint rule that flags property accesses like `changes.foo` where `changes` is a `SimpleChanges` object, because they'll break under Closure compiler. The rule depends on the TS type checker to identify the objects, but it seems like somewhere along the way, tslint changed how they construct the `Program` which removed the necessary type information. These changes add a less complicated fallback which looks at whether the name of the receiver of a property access is the same as the name of the first method parameter. (cherry picked from commit 2465131)
|
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. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #21074. We have a lint rule that flags property accesses like
changes.foowherechangesis aSimpleChangesobject, because they'll break under Closure compiler. The rule depends on the TS type checker to identify the objects, but it seems like somewhere along the way, tslint changed how they construct theProgramwhich removed the necessary type information.These changes add a less complicated fallback which looks at whether the name of the receiver of a property access is the same as the name of the first method parameter.