feat(compiler-cli): add extended diagnostics to check for component v…#48658
Conversation
e43432c to
10b7a88
Compare
|
@jessicajaniuk @AndrewKushnir |
JoostK
left a comment
There was a problem hiding this comment.
There's a few more cases that such check would need to take into account:
- Inherited properties will not cause the message to be reported.
- Template scopes can shadow ancestor template variables:
<div *ngFor="let local of []">
<button #local></button>
</div>Here, #local shadows the let-local declaration of the ng-template element that is created by the structural ngFor directive.
AndrewKushnir
left a comment
There was a problem hiding this comment.
@robertIsaac thanks for the PR 👍
I've left some comments, including additional information about build failures from the internal tests run.
There was a problem hiding this comment.
The deep link here is the reason for the internal test failures. Could you please update it to avoid the deep link?
| import {Reference} from '@angular/compiler/src/render3/r3_ast'; | |
| import {TmplAstReference as Reference} from '@angular/compiler'; |
There was a problem hiding this comment.
I see there is more imports from src/render3/r3_ast, should I fix them as well?
There was a problem hiding this comment.
This line is also causing some issues, could you please update it as well?
| import ts, {Identifier} from 'typescript'; | |
| import ts from 'typescript'; |
and use ts.Identifier in the code below.
There was a problem hiding this comment.
There are 3 other build errors, presumably related to the lack of type-narrowing for the node (potentially related to the deep linking issue above):
packages/compiler-cli/src/ngtsc/typecheck/extended/checks/component_variable_shadow_template_reference/index.ts:32:36 - error TS2339: Property 'name' does not exist on type 'Node | AST'.
Property 'name' does not exist on type 'Node'.
32 const templateReference = node.name;
~~~~
packages/compiler-cli/src/ngtsc/typecheck/extended/checks/component_variable_shadow_template_reference/index.ts:41:9 - error TS2345: Argument of type 'ParseSourceSpan | AbsoluteSourceSpan' is not assignable to parameter of type 'ParseSourceSpan'.
Type 'AbsoluteSourceSpan' is missing the following properties from type 'ParseSourceSpan': fullStart, details
41 node.sourceSpan,
~~~~~~~~~~~~~~~
and an error related to the implicit any type in the following code:
packages/compiler-cli/src/ngtsc/typecheck/extended/checks/component_variable_shadow_template_reference/index.ts:34:31 - error TS7006: Parameter 'member' implicitly has an 'any' type.
34 component.members.map(member => (member.name as Identifier)?.escapedText.toString());
~~~~~~
There was a problem hiding this comment.
do I need to explicitly provide type to member or what? because in my IDE it shows correctly member: ts.ClassElement
There was a problem hiding this comment.
| * @COMPONENT({ | |
| * @Component({ |
There was a problem hiding this comment.
| * A variable in the component shadow the same name as a template reference. | |
| * A template reference shadows a component class property or method. |
There was a problem hiding this comment.
| COMPONENT_VARIABLE_SHADOW_TEMPLATE_REFERENCE = "ComponentVariableShadowTemplateReference", | |
| COMPONENT_VARIABLE_SHADOWS_TEMPLATE_REFERENCE = "ComponentVariableShadowsTemplateReference", |
There was a problem hiding this comment.
I renamed everything to be shadows
53b6526 to
c1e974a
Compare
so members of the component return only direct members? is there anyway to get all the members of a class?
oh I missed this when I was solving the solution, will see what I can do about it tomorrow |
|
@JoostK I found making
|
Indeed, |
@JoostK I don't get what you mean here, |
7d2df67 to
4a79c47
Compare
|
@JoostK I made test cases to check how actually angular will work with edge cases and it seems things are actually more complicated than what I originally thought so the acceptance criteria from my opinion is:
do you think there is more edge cases I should consider? |
4a79c47 to
c4fa18c
Compare
|
@AndrewKushnir @JoostK any update about this PR? |
|
Can you rebase your branch to fix the conflicts ? (Error 8108 is now taken). |
fc18891 to
99ab9f4
Compare
done do you plan to accept it? |
|
@robertIsaac looks like you have failing status checks. You'll need to resolve those first. One of them is showing that you need to update goldens now that you've added this check. |
|
(You'll need to run |
99ab9f4 to
ab8c6c2
Compare
done |
ab8c6c2 to
ae70936
Compare
…ariable shadowing template reference for example ``` @component({ template: '<div #var1></div>' }) export class FooComponent { var1: string; } ``` right now this goes without error, but it can lead to mistakenly inside the template to use the template reference as if it was the component variable Fixes angular#45227
…ariable shadowing template reference for example ``` @component({ template: '<div #var1></div>' }) export class FooComponent { var1: string; } ``` right now this goes without error, but it can lead to mistakenly inside the template to use the template reference as if it was the component variable Fixes angular#45227
ae70936 to
fd2b2ec
Compare
|
We discussed this just now and decided to close this for now, as the PR in its current state is not ready to land:
|
|
hi @JoostK thanks for your feedback |
|
You'd also have to go from the const properties = ctx.typeChecker.getPropertiesOfType(ctx.typeChecker.getTypeAtLocation(component)); |
|
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. |
…ariable shadowing template reference
for example
fixes #45227
right now this goes without error, but it can lead to mistakenly inside the template to use the template reference as if it was the component variable
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?
Issue Number: 45227
What is the new behavior?
it will show warning when there is shadowing between component variable and template reference
Does this PR introduce a breaking change?
I guess it's not, because it's a warning not an error, but I'm leaving it for the Angular team to decide
to fix the warning, simply rename the component variable or the template reference
Other information
this will show the warning even if the component variable is private, which in my opinion is correct
but in case the Angular team disagree, I will make it only show the warning in case of protect or public variables only