Tslint: interface-over-type-literalは推奨されるべきではありません

申し訳ありませんが、意味がわかりません。 これは機能リクエストですか、それともバグレポートですか？

Recommendationd.tsのinterface-over-type-literalのデフォルト値はtrueです。 私はそれが間違っているべきだと信じています。 それが機能のリクエストなのかバグなのかわからない:-)

結局、推奨されるプリセットは意見が分かれています。 上記で投稿したようなベストプラクティスと提案が組み込まれています。
プリセットを拡張する場合、推奨事項を上書きして、必要に応じて構成を調整できます。

とにかく、ルールを無効にすることは重大な変更になります。 したがって、次のメジャーバージョンの前に変更を期待しないでください。

明確にするために： interface-over-type-literalは、型エイリアス宣言についてのみ文句を言います。

type Foo = {foo: number}; // The rule disallows this
interface Foo {foo: number} // and fixes it to this

let obj: {foo: number}; // This is still allowed

タイプエイリアスとインターフェイスは（ほぼ）交換可能に使用できるため、タイプエイリアスを使用する理由がわかりません。

関連する注意事項：インターフェイスはキャッシュされていましたが、タイプエイリアスなどの匿名タイプは常に使用できるように再計算されていました。 したがって、型エイリアスを使用すると、コンパイル時間が大幅に増加する可能性があります。
そのパフォーマンスのギャップは、次のtypescriptバージョンでほとんどなくなります。

私はそれを上書きできることを知っていますが、推奨が間違っていると強く感じています。

これが私の見解です。 タイプエイリアスにインターフェイスを使用できない場合が多くあります。 インターフェイスを使用してオブジェクトリテラルを入力することしかできません。 推奨されるベストプラクティスに従う場合、複数の型エイリアスがある特定のクラスファイルでは、一部は型エイリアスになり、一部はインターフェイスになります。 このクラスに出くわした人は、一体何が起こっているのか、そしてインターフェイスをどこかに実装/拡張するつもりなのか、少なくとも可能性があると期待しているのか疑問に思うでしょう。

私の意見では、インターフェイスに追加の機能があるという理由だけで（必要のない）、ある場合には一方を他方に置き換えるのではなく、タイプエイリアスにタイプエイリアスを使用し、インターフェイスにインターフェイスを使用する方がはるかにクリーンです。すべてが必要な場合はタイプエイリアス）。

typescriptドキュメントに対して問題を作成する必要があると思いますが、ドキュメントに記載されているという理由だけでルールを実装するのではなく、ここでエンジニアリング上の判断を適用できると思います。

私の意見では、構造体にinterfaceキーワードを使用することは実際には推奨されません。 このルールは正反対のことをするので、これがベストプラクティスと見なされる方法はありません。

これは、タイプスクリプトが私の意見で間違っていたものの1つです。これは、インターフェイスの概念を混乱させています。これは、私が使用した他のすべてのタイプセーフ言語でのセマンティクスが、オブジェクト署名付きの「メソッド/関数/呼び出し可能なもののコレクション」を意味します。ダックタイプ。 インターフェイスの使用はより制限的である必要があり、TSLintルール「interface-must-declare-only-functions」またはより制限の少ない「interface-must-declare-at-least-one-function」を歓迎します。

純粋な構造は、型演算子を使用して宣言し、＆演算子を使用して拡張する必要があります。 そして、名前は「T」で始まる必要があります:-)

@navels私はあなたのフィードバックに同意します、私はtslint:recommendedが次のメジャーバージョンの重大な変更としてこの過度に意見のあるルール構成を削除するべきだと思います

このオプションを上書きするにはどうすればよいですか？

tslint.jsonの@sibeliusは、$＃$ "rules"の下で、 falseとしてマークします。

{
    "extends": ["tslint:recommended"],
    "rules": {
        "interface-over-type-literal": false
    }
}

この問題は、推奨されるルールセットでルールを無効にすることを追跡していることに注意してください。 TSLintに関する一般的な質問がある場合は、StackOverflowまたはGitterのいずれかを使用してください。

ここで誰かがこの主題について話しますhttps://medium.com/@martin_hotell/interface-vs-type-alias-in-typescript-2-7-2a8f1777af4c

ルールの上書きについては、インターフェースの代わりにタイプを使用するように強制するオプションをお勧めします。さらに、反応でPropsまたはStateを定義している場合にのみタイプを使用するように強制します。成分。

私は、現在のプロジェクトでまったく使用していないところまで、OOPコードをどんどん書いています。
私は初心者がそれに向かって少しずつ動かされてほしくない。

@dandreiと私は、関数を記述したい場合にのみインターフェースを使用します（私もOOPを使用しません）。

ええ、これは間違いなく間違っているので、IMOを推奨の一部にするべきではなく、少なくとも自動修正しないでください。そうすれば、タイプが壊れる前に無効にできます。

推奨事項は実際にはコードを壊します。 検討：

type Foo = {
  foo: string
}

interface IndexedObject {
  [key: string]: string
}

function useIndexedObject(object: IndexedObject) {}

const foo: Foo = {foo: "foo"}
useIndexedObject(foo)

上記のコードは機能します。 tslint --fixが適用され、 type Fooがinterface Fooに変更されるまで、最後の行でエラーが発生します。

Argument of type 'Foo' is not assignable to parameter of type 'IndexedObject'.
  Index signature is missing in type 'Foo'.

IMO、コードを破るルールは推奨すべきではありません。 一体、それがコードを壊す可能性があるのなら、それは規則でさえあるべきではありません。

それだけでなく、「インターフェースは「I」で始まらなければならない」というルールも発生します。

error TS2344: ...
Index Signature is missing in type 'SOME INTERFACE'.

だから私はタイプを使わなければなりません。

アプリの使用量がtypeである場合は、SOLIDの原則に違反していることを示す良い指標です。

＃4811ごとにType: Breaking Changeラベルを削除します。 PR受付中！

では、InterfaceScriptという名前にする必要があるのに、なぜTypeScriptと呼ばれるのでしょうか。 🤣