Thanks to visit codestin.com
Credit goes to github.com

Skip to content

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

Closed
wants to merge 1 commit into from

Conversation

crisbeto
Copy link
Member

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).

if (reference.getIdentityInExpression(rawImports) !== null) {
return true;
}

Copy link
Member Author

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.

Copy link
Member

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 👍

Copy link
Member

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]].

Copy link
Member Author

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.

@crisbeto crisbeto requested review from JoostK and alxhub September 24, 2024 07:50
@crisbeto crisbeto added action: review The PR is still awaiting reviews from at least one requested reviewer target: major This PR is targeted for the next major release area: compiler Issues related to `ngc`, Angular's template compiler labels Sep 24, 2024
@ngbot ngbot bot modified the milestone: Backlog Sep 24, 2024
@crisbeto crisbeto marked this pull request as ready for review September 24, 2024 07:50
if (reference.getIdentityInExpression(rawImports) !== null) {
return true;
}

Copy link
Member

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 👍

Comment on lines 167 to 168
// Otherwise only report declarations referenced through
// a non-exported array within the same file.
Copy link
Member

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.

Copy link
Member

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.

Copy link
Member

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.

Copy link
Member

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?

…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).
@angular-robot angular-robot bot removed the area: compiler Issues related to `ngc`, Angular's template compiler label Sep 25, 2024
@ngbot ngbot bot removed this from the Backlog milestone Sep 25, 2024
Copy link
Member Author

@crisbeto crisbeto left a 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;
}

Copy link
Member Author

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.

@crisbeto crisbeto added action: merge The PR is ready for merge by the caretaker and removed action: review The PR is still awaiting reviews from at least one requested reviewer labels Sep 26, 2024
@crisbeto crisbeto removed the request for review from alxhub September 26, 2024 06:26
@alxhub
Copy link
Member

alxhub commented Sep 30, 2024

This PR was merged into the repository by commit 33fe252.

The changes were merged into the following branches: main

@alxhub alxhub closed this in 33fe252 Sep 30, 2024
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Oct 31, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker target: major This PR is targeted for the next major release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants