Tslint: Rule request: no-duplicate-super

Created on 5 Jan 2017  路  6Comments  路  Source: palantir/tslint

TypeScript code being linted

class Foo { }

class Bar extends Foo {
    constructor() {
        super();
        super();
    }
}

Actual behavior

No problems - JavaScript and TypeScript allow this.

Expected behavior

Calling super() twice is probably not the intended behavior. It's more likely to be a copy&paste error or improper source control merge.

P2 Fixed Rule Suggestion

Most helpful comment

To be clear, it was always a reference error per 262. tc39/ecma262#762 merely proposes that the reference error should occur prior to invoking the super constructor (since it seems surprising that the second super half "works" in its current form).

All 6 comments

FWIW, this was also just PRd as a reference error into the ECMA 262 spec. https://github.com/tc39/ecma262/pull/762

To be clear, it was always a reference error per 262. tc39/ecma262#762 merely proposes that the reference error should occur prior to invoking the super constructor (since it seems surprising that the second super half "works" in its current form).

Given that TypeScript accepts this code, which then fails at runtime, have you tried making an issue on TypeScript?

@andy-hanson I suggested it to @bterlson, who pointed it that the following behavior is hard to catch:

class Foo {
    constructor() {
        if (Math.random() > .99) super();
        super();
    }
}

Getting in the business of determining when a super() call is redundant isn't really something the language team should be taking on. The very obvious case is something a linter could do.

Given that TypeScript accepts this code, which then fails at runtime, have you tried making an issue on TypeScript?

I request that this rule is re-evaluated, given that in 2019 ESLint is replacing TSLink. It does not seem suitable to add this within the typescript subset of rules when it is applicable to standard javascript too.

Please note that the current tc39/ecma262#762 conclusion appears to be that it is not worth the run-time cost. This is the last update on this matter.

@ajklein - Aug 22, 2018

My opinion is that changing this isn't worth any runtime cost at all. I'd be curious for @bterlson's opinion on that question as well.

If it is applicable to standard javascript, you should file the request in an ESLint-related repo, not here.

Was this page helpful?
0 / 5 - 0 ratings