Tslint: Semicolon rule ignores methods

[movedoa]

Bug Report

• __TSLint version__: 4.0.2
• __TypeScript version__: 2.1
• __Running TSLint via__: Atom

Actual behavior

TsLint ignores semicolons at the end of methods, regardless of the settings

Expected behavior

TsLint should report these

[chippydip]

It also seems to be ignoring semicolons after the closing brace of a class/interface.

[adidahiya]

Both of those are intentional. Classes / interfaces typically do not have trailing semicolons because they are not statements.

As for semicolons at the end of bound class methods -- the behavior was changed in v4.0. See https://github.com/palantir/tslint/issues/1476

[chippydip]

Right, they shouldn't have trailing semicolons because they aren't statements and I thought there used to be a warning if one was given.

class Foo {
    bar() {
    }; // <- why is this not a warning

    baz = () => {
    }; // <- but this is a warning
}

Testing a bit more, it seems like extraneous semicolons are fine anywhere except for after a bound function. I thought they used to generate warnings, but maybe I'm mis-remembering. In any event, the main rationale for changing the behavior on bound functions was to be consistent with regular method so if it's going to complain about a trailing semicolon on a bound function it really should also complain about a trailing semicolon on a regular function as well (and probably any extraneous semicolons).

[adidahiya]

Ah, I see what you're getting at, that makes sense. Right now the "always" option mostly just enforces the existence of semicolons in certain positions and only disallows semicolons in one position. The semantics could use some cleaning up; perhaps the reporting of "unnecessary" semicolons belongs in another rule option?

[chippydip]

Yeah, it would definitely make a lot more sense to me if there were separate rules for missing semicolons and for unnecessary semicolons.

[nchen63]

Wouldn't it make more sense as more granular options of the semicolon? Otherwise, with 2 rules, there is potential for one rule to conflict with another

[adidahiya]

@nchen63 yeah, that's what I was suggesting in my comment

[adidahiya]

closing in favor of #2015, which is a more direct issue report