Skip to content

build: stricter unused variable checking #6633

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

Merged

Conversation

devversion
Copy link
Member

Currently only variables that don't start with an underscore will be checked by TSLint.

This doesn't make sense, because variables get prefixed with an underscore to indicate that they are not part of the public API, but still need to be public in favor of AOT compilation for example. This means that those properties are having the public modifier set (explicitly or automatically) and therefore won't be treated as unused anyway.

TL;DR: With this change, prefixed variables will be checked by the no-unused-variable TSLint rule and those which are marked as private and are unused will be catched by TSLint.

@googlebot googlebot added the cla: yes PR author has agreed to Google's Contributor License Agreement label Aug 25, 2017
@@ -281,7 +281,7 @@ class MdPaginatorApp {

@ViewChild(MdPaginator) mdPaginator: MdPaginator;

constructor(private _elementRef: ElementRef) { }
constructor() {}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can remove this constructor.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

Currently only variables that don't start with an underscore will be checked by TSLint.

This doesn't make sense, because variables get prefixed with an underscore to indicate that they are not part of the public API, but still need to be public in favor of AOT compilation for example. This means that those properties are having the public modifier set (explicitly or automatically) and therefore won't be treated as unused anyway.

**TL;DR**: With this change, prefixed variables will be checked by the `no-unused-variable` TSLint rule and those which are marked as `private` and are unused will be catched by TSLint.
@devversion devversion force-pushed the build/stricter-no-unused-variable branch from a534d55 to 775b0f8 Compare August 25, 2017 10:21
@@ -89,6 +89,7 @@ export class StartWithBrand { private _; }
export class DebounceTimeBrand { private _; }
export class AuditTimeBrand { private _; }
export class TakeUntilBrand { private _; }
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 ok with having these properties be public. They're not a part of any API or generated JS anyway.

Copy link
Member Author

@devversion devversion Aug 25, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I don't mind either. I just changed it

Edit: Actually it looks like making the property public causes TypeScript to complain.

Copy link
Member

@jelbourn jelbourn Aug 28, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The brand properties actually must be private, otherwise they are structurally identical to each other

@devversion devversion force-pushed the build/stricter-no-unused-variable branch from 336b331 to 775b0f8 Compare August 25, 2017 11:13
Copy link
Member

@jelbourn jelbourn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jelbourn jelbourn added P4 A relatively minor issue that is not relevant to core functions pr: lgtm action: merge The PR is ready for merge by the caretaker and removed pr: needs review labels Aug 28, 2017
@jelbourn jelbourn merged commit 28ede30 into angular:master Sep 1, 2017
@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 Sep 7, 2019
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 cla: yes PR author has agreed to Google's Contributor License Agreement P4 A relatively minor issue that is not relevant to core functions
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants