New Rule: param-property-in-constructor

[ChrisMBarr]

New rule created based on discussions in #1336

The rule is named no-improper-constructor-param-usage and has no configuration options.

Here’s a quick code sample of what will trigger a violation

constructor(public foo: number) {
    this.foo = 10;
    foo = 5; //<-- violation
}

[ChrisMBarr]

Sorry about the merge commits. I thought github desktop was better than that! I'll do it from the command line in the future.

[jkillian]

How do you feel about the name param-property-in-constructor? "no-improper" feels like an uneeded double-negative to me, and "usage" seems unnecessary. "Parameter properties" is the official name the TS docs use for this sort of a construct, so I wanted to get that in the rule name

[jkillian]

You could just make this private languageService: ts.LanguageService if you want (funny considering what this rule does 😄 )

[ChrisMBarr]

lol, ugh why did I not notice this! 😆

[jkillian]

for-of usage is preferred when you don't need an index argument. (I think this is for performance reasons?)

[adidahiya]

Performance and consistency (one iteration style)

[ChrisMBarr]

The test failures seem to be related to changes that were made before this branch was started. I think it would be fine to merge into master, but please double check me.

Also ignore my commit on a new branch there, i was trying to simplify things but accidentally made it more complex. so just ignore that extra branch.

[jkillian]

Can you merge master here as well, so we can see the CI passing before merging this PR?

[jkillian]

Hmm, I wasn't thinking about this use case. When accessing a value, it doesn't matter if you use this. or not. Do you think we should still disallow this?

[jkillian]

On the other hand, using this. doesn't hurt

[ChrisMBarr]

yeah that was my thinking with the way it was written initially. I was thinking that if we just require this. on everything, then there is consistency for how all constructor params are used, regardless if they are used as properties or not.

[jkillian]

Hmm, actually looks like TS has some sort of similar functionality build in: microsoft/TypeScript#10062

[YuichiNukiyama]

@jkillian You're right. We can validate unused parameter property with --noUnusedParameters option.
This feature already has been implimented in TS2.0 beta. And my PR (#10062) only intend to change error message. see Flag unused declarations with --noUnusedParameters and --noUnusedLocals .

[adidahiya]

related: #1481

[jkillian]

I don't think the benefits of this rule are worth it given the features in TS 2.0. Sorry @ChrisMBarr! Let me know if you strongly disagree

[ChrisMBarr]

@jkillian :Some code I saw today in a project lead me back here to see why this PR was never accepted. Reading over the above comments, I'm not entirely sure now.

The intent of this PR was not to find unused constructor parameters, it was meant to enforce the correct usage of those parameters.

constructor(public foo: number) {
    this.foo = 10;
    foo = 5; //<-- violation
}

I can re-submit this PR, but I don't want to put the work in for it unless it's desired.