Codelyzer: [Feature request] - check unused properties in class declaration

[Teamop]

Right now, there's an edge case that doesn't covered by tslint, codelyzer and language service.
The demo is easy, just use http://codelyzer.com/, then just add a: string; in the component, like this:

Here, no error, no warning.

For TSLint, only complains about unused private properties, but for angular template usage, the properties must be public for AOT.

There was a similar but opposite rule no-access-missing-member which has been removed for language service, so I'm not sure whether I should submit this issue here or in the language service.

[mgechev]

@Teamop the feature request is to detect properties which are not later read?

[Teamop]

@mgechev yes, just declare but don't use.

[mgechev]

Following the feature request process that lodash has, I'm closing the issue and adding votes needed label.

Later we can prioritize the feature requests by popularity and include them in a future release.

[rafaelss95]

@mgechev Do you have any idea on how to start the implementation for this rule?

[mgechev]

Not sure if it's possible to solve this in the general case.

The property can be accessed from outside of the component.

[wKoza]

yes, and we have had lot of problem with inheritance...

[buu700]

My request (#810) was pretty much the same as this, with the addition that it should flag methods that aren't referenced in the template, not just class variables.

Also, an additional consideration comes to mind: in the case of both variables and methods, I think we should overlook anything specified by an implemented interface by default. e.g. no need to complain that ngOnInit is never called, because we can see that it's required by OnInit.

[buu700]

Not sure if it's possible to solve this in the general case.

The property can be accessed from outside of the component.

I don't know whether you'd consider this an acceptable solution, but this was my suggestion in the other ticket:

There are certainly some edge cases where a public member might be needed without having been referenced in the template, but I think these would be the vast minority of cases, and so would be fine for most projects to just comment with one-off lint exceptions.