-
Notifications
You must be signed in to change notification settings - Fork 26.3k
fix(compiler-cli): do not report unused declarations coming from an imported array #57940
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
if (reference.getIdentityInExpression(rawImports) !== null) { | ||
return true; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Disclaimer: I'm not entirely sure if this is the best way to find which array the symbols was imported by.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this approach is okay 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this will catch a few things you might not expect too, such as inline nested arrays imports: [X, Y, [Target, Z]]
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that reporting imports: [X, Y, [Target, Z]]
is the correct behavior since it's defined inline. What I want to avoid is arrays shared between components.
packages/compiler-cli/src/ngtsc/validation/src/rules/unused_standalone_imports_rule.ts
Outdated
Show resolved
Hide resolved
if (reference.getIdentityInExpression(rawImports) !== null) { | ||
return true; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this approach is okay 👍
// Otherwise only report declarations referenced through | ||
// a non-exported array within the same file. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would consider it meaningful the extend this comment with the why. AFAIK this is just a heuristic to determine if the array is possibly shared, and therefore shouldn't be considered owned by the template.
Note that this heuristic has a limitation, where multiple components in the same file that reuse a single constant array may report false positives. These could potentially be avoided by also keeping track of which identifiers are used, and then have a post-file visit operation to determine after the source file has fully been scanned which of the unused identifiers are unused throughout the source file. I'm not sure if that is worth it, but perhaps good to note in the comment here the possibility for false positives.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to have this nuance? Clear and simple rules are preferable to heuristics in a lot of cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be fine keeping this simple, but I would call this out in a comment to at least capture that it's been considered and decided against for simplicity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or do you mean the nuance of differentiating between exported arrays at all?
packages/compiler-cli/src/ngtsc/validation/src/rules/unused_standalone_imports_rule.ts
Outdated
Show resolved
Hide resolved
…mported array Some apps follow a pattern where they have an array of common declarations which is imported in most standalone components, but only some of the declarations are used. Such cases will currently raise the unused imports diagnostic but can be hard to fix, because it would require either removing declarations from the common array which can break other components, or copying only the necessary declarations from the array. Since neither of these solutions is great, this commit tweaks the logic for the diagnostic so that unused imports coming from _exported_ arrays are not reported (either from the same file or another one).
47dc321
to
ff1c013
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've addressed the feedback.
if (reference.getIdentityInExpression(rawImports) !== null) { | ||
return true; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that reporting imports: [X, Y, [Target, Z]]
is the correct behavior since it's defined inline. What I want to avoid is arrays shared between components.
This PR was merged into the repository by commit 33fe252. The changes were merged into the following branches: main |
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. |
Some apps follow a pattern where they have an array of common declarations which is imported in most standalone components, but only some of the declarations are used. Such cases will currently raise the unused imports diagnostic but can be hard to fix, because it would require either removing declarations from the common array which can break other components, or copying only the necessary declarations from the array. Since neither of these solutions is great, this commit tweaks the logic for the diagnostic so that unused imports coming from exported arrays are not reported (either from the same file or another one).