Skip to content
This repository has been archived by the owner on Mar 25, 2021. It is now read-only.

no-empty-interface: allow providing type arguments for extended type #3260

Merged
merged 1 commit into from Oct 20, 2017
Merged

no-empty-interface: allow providing type arguments for extended type #3260

merged 1 commit into from Oct 20, 2017

Conversation

ajafff
Copy link
Contributor

@ajafff ajafff commented Sep 28, 2017

PR checklist

Overview of change:

[bugfix] no-empty-interface allows providing type arguments for extended type
Fixes: #3256

Is there anything you'd like reviewers to focus on?

The rule now ignores every interface whose parent has type arguments. That leads to some false-negatives:

interface Base<T> {
    prop: T;
}

interface Good extends Base<string> {}
interface Bad<T> extends Base<T> {}
interface ProbablyGood<T extends string> extends Base<T> {}
interface ProbablyGood2<T = string> extends Base<T> {}

interface Base2<T, U = void> {
    prop: T,
    prop2: U;
}

interface Bad2<T, U> extends Base2<T, U> {}
interface Good2<U, T> extends Base2<T, U> {}
interface Good3<T> extends Base2<T> {} // looks like `Bad`, but isn't ... would require the type checker

There will be no error on any of these declarations. One might expect errors on Bad and Bad2 (and maybe even on ProbablyGood, ProbablyGood2 if the base type has the same default and/or constraint) but that requires the type checker to find out about all type parameters of the base type.

I don't know if these rare cases are worth the effort. Anyways, that should be done in a separate PR.

CHANGELOG.md entry:

[bugfix] `no-empty-interface` allows providing type arguments for extended type
Fixes: #3256
@adidahiya adidahiya self-assigned this Oct 19, 2017
Copy link
Contributor

@adidahiya adidahiya left a comment

Choose a reason for hiding this comment

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

nice, yeah, keeping it simple here is good

@adidahiya adidahiya merged commit 561cb58 into palantir:master Oct 20, 2017
@ghost
Copy link

ghost commented Oct 30, 2017

Could this be put behind an option? I'd like to still get errors for interface T extends U<string> {} on DefinitelyTyped as this can just be type T = U<string>;.

HyphnKnight pushed a commit to HyphnKnight/tslint that referenced this pull request Apr 9, 2018
…alantir#3260)

[bugfix] `no-empty-interface` allows providing type arguments for extended type
Fixes: palantir#3256
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

no-empty-interface should not fail on an interface that resolves types
2 participants