Tslint: 提案：条件付きリント構成

テストと本番コードを別々のディレクトリに置く場合、そのような機能は必要ありません。 CLI引数として構成ファイルを指定しない場合、TSLintは最も近いtslint.jsonます。 したがって、フォルダごとに異なる設定を行うことができます。 "extends"を使用すると、同じ基本構成を使用して、特定のルールのみをオーバーライドできます。

多くのAngularプロジェクトとReactプロジェクトが、対応する本番コードと同じディレクトリにテストを配置していることがわかりました。 個人的にはこれは悪い習慣だと思います。 私は十分な数の人々が（偶然に）本番コードのテストからシンボルをインポートするのを見てきました。

IMOが提案する機能は、多くの複雑さを追加します。 実装はそれほど難しくないかもしれませんが、設定ファイルを読んで理解するのが難しくなります。
これを実装する場合は、2番目の提案をお勧めします。

また、構成を拡張するときにどのように機能するかについても説明する必要があります。 オーバーライドはどの順序で適用されますか？

確かに、コードを分離することもできますが、人間工学に悪影響を及ぼします。 どちらか

src/
  tslint.json
  a/
    b/
      c/
test/
  tslint.json (extends ../src)
  a/
    b/
      c/

そしてc/foo.spec.tsはimport {symbol} from '../../../a/b/c/foo';なければなり

そのパスは、ファイルがツリーの非常に深いところにあることが多いモノリポジトリでは醜くなります。

またはあなたが持っている

  a/
    src/
      tslint.json
    test/
      tslint.json (extends ../src)
    b/
      src/
        tslint.json
      test/
        tslint.json (extends ../src)
      c/
        src/
           tslint.json
        test/
          tslint.json (extends ../src)

tslint.jsonファイルが多すぎます

オーバーライドのトピックについて：オーバーライドは、ルールが適用されるのと同じ順序で適用されると思います。 それが何であるかわからず、ドキュメントも見つかりませんでしたが、直感的には次のようになると思います。

// a.json
{"rules": {"foo": [true, 1]}}

// b.json
{"rules": {"foo": [true, 2]}}

// c.json
{
  "extends": ["a.json", "b.json"],
  "rules": {"foo": [true, 3]}
}

ルール「foo」の引数は3になります。そのルールがc.jsonにない場合、「extends」配列の順序により、「foo」の値は2になります。

オーバーライドについては、同じ順序が適用されることを期待します。 'extends'ルールが考慮される順序を考慮して、提供された正規表現に一致する最後のオーバーライドを使用することは私には理にかなっています。 単一ファイルの例：

{
  "rules": {"a": [true, 1]},
  "override": [
    {"match": "test|spec", "rules": {"a": [true, 2]}},
    {"match": "test", "rules": {"a": [true, 3]}}
  ]
}

ファイルパスに「spec」が含まれている場合はルール「foo」の値が2、「test」が含まれている場合は3、それ以外の場合は1になります。 （明らかに、「テスト」は最初から省略された方がよいので、あまり有用なオーバーライドのセットではありませんが、あなたはその考えを理解します）

それは理にかなっていて、あなたの質問に答えますか？

@calebegg考慮すべき他のエッジケースがいくつかあります。

// a.json
{
  "rules": {"foo": [true, 1]},
  "override": {"match": "test|spec", "rules": {"foo": [true, 2]}}
}

// b.json
{
  "extends": "./a.json"
  "rules": {"foo": false}
}

期待される結果は何ですか？

• 2オーダーであるため、 a.json/rules > - b.json/rules - > a.json/override
• 注文がa.json/rules -> a.json/override -> b.json/rulesため、 false b.json/rules

ここでも同じですが、期待される結果は何ですか。

// c.json
{
  "rules": {"foo": [true, 1]},
  "override": {"match": "test|spec", "rules": {"foo": false}}
}

// d.json
{
  "extends": "./a.json"
  "rules": {"foo": {"options": 2}},
  "override": {"match": "test|spec", "rules": {"foo": {"options": 3}}}
}

ただランダムな考え：パターンを順番に一致させ、（部分的に）前の一致をオーバーライドしないのはなぜですか？

{
  "rules": { // same as "*"
    "rule-one": true,
    "rule-two": true
  },
  "*.js?(x)": { // we could get rid of "jsRules" with this
    "rule-two": false
  },
  "*.{t,j}sx": {
    "jsx-rule": true
  },
  "*.spec.*" {
    "rule-one": false
  }
}

いくつかの例：

• foo.ts ：ルール-1、ルール-2
• foo.tsx ：ルール1、ルール2、jsxルール
• foo.js ：ルール1
• foo.jsx ：ルール1、jsxルール
• foo.spec.tsx ：ルール2、jsxルール
• foo.spec.js ：なし

これを設定内のどこに置くかわかりません。 "rules"と同じレベルでは、書きやすくなりますが、 "extends" 、 "rulesDirectory" 、..と同じレベルであるため、ユーザーを混乱させる可能性があります。

もう1つの問題は、構成の拡張です。 基本構成からのすべてのオーバーライドを適用してから、現在の構成からのオーバーライドを適用すると、理解するのがかなり難しくなります。

また、コードがより複雑になります。 現在、構成は解析中にマージされます。 この提案では、最終的な構成は、ファイル名がある場合にのみわかります。

こんにちは、

この機能は素晴らしいでしょう。 Eslintはこの機能をサポートしていると思います： https ：//eslint.org/docs/user-guide/configuring#configuration-based-on-glob-patterns。 したがって、混乱を避けるために、構文とセマンティクスは同じにすることができます。

@minomikulaどうもありがとうございました。 以前にESLintドキュメントを検索しましたが、このセクションが見つかりませんでした。

彼らのアプローチは理にかなっています。 要約する：

• "overrides"セクションには、オーバーライドの配列が含まれています
• オーバーライドでは、複数のグロブパターン（ "files" ）を指定できます。 それらの1つが一致する場合、構成が適用されます
• グロブパターンでファイルを除外できます： "excludedFiles"
• グロブパターンは、それらが指定されている構成ファイルに関連しています
• グロブパターンは、ベース名だけでなく、常にパス全体と一致する必要があります
• オーバーライドは順番に処理され、前のオーバーライドがオーバーライドされます
• 構成ファイルを拡張する場合、拡張構成に進む前に、基本構成が完全に評価されます。
  
  
  
  • base.json / rules
  
  
  • base.json / overrides
  
  
  • extended.json / rules
  
  
  • extended.json / overrides
  
  

この動作をTSLintに移植する際には、考慮すべきことがいくつかあります。

• オーバーライドでextendsとlinterOptionsを確実に無効にする必要があります
• おそらくrulesDirectoryも禁止したいと思います
• オーバーライドでrulesとjsRulesを許可しますか、それとも**/*.js?(x)オーバーライドを優先してjsRulesを廃止しますか？

考えやコメント@ adidahiya @ calebegg

ああ、すごい、ええ、そのアプローチは私には合理的なようです。 私も先行技術を探すべきだった。

これは素晴らしい追加になるでしょう！ eslintアプローチは、テストファイルの一部のルールを条件付きで無効にする場合に最適です。

@calebegg時間があれば、これを進める予定はありますか？

はい、絶対にこれに取り組みたいと思います。 @ajafff ESLintアプローチから始めて、PRを繰り返すことに一般的に満足していますか？ それとも、最初に話し合うべき設計上の質問があると思いますか？

オーバーライドでルールとjsRulesを許可しますか、それとも* / .js？（x）オーバーライドを優先してjsRulesを廃止しますか？

非推奨にすることは私には理にかなっていますが、どちらにしてもあまり強くは感じません。

@calebeggESLintアプローチで大丈夫です。 私はPOCリンターランタイムに非常によく似た概念を実装しましたhttps://github.com/fimbullinter/wotan/tree/master/packages/wotan#overrides

現在のTSLintAPIは、解析中にすべての構成をマージするため、統合は難しい場合があります。 これは、ファイルの名前がわかるまで延期する必要があり、すべてのファイルに対して実行する必要があります。

これは確かにAPIの重大な変更です。

@calebegg @mitchlloyd @ajafff @alexeagle tslint.jsonファイルをネストして外部構成をオーバーライドするよりも、この機能にはほとんどメリットがありません。 この機能は現在すでに機能しており、複雑なAPIブレークは必要ありません。 このリクエストを拒否した場合、気分を害しますか？

ネストは、ここで説明する問題を解決しません。 多くの人は、テストするコードと同じディレクトリ構造でテストを

ソースと同じディレクトリにスペックファイルを配置するプロジェクトがたくさんあります。 これは多くの環境でのベストプラクティスになりました。AngularCLIはそのようなプロジェクト構造を生成します。tslint構成ファイルをネストすることはこれらすべての人々にとって現実的ではないと思います。

私のプロジェクト構造はリンティングツールによって決定されるべきではないことに同意します。 代わりに、リンティングツールは一般的な既存のパターンをサポートする必要があります。 テストとソースファイルを同じ場所に配置するのが一般的なパターンです。

@giladgray要求された変更は、ユーザーが次のようにテストファイルと本番ファイルを

some-dir/
  my-component.ts
  my-component.test.ts

my-component.tsとmy-component.test.ts異なるルールが必要な場合、「 tslint.jsonファイルのネスト」はこのユースケースにどのように対処しますか？

@giladgray角度ガイドラインでは、テストをファイルと一緒に配置することを推奨しています。 したがって、角度のあるプロジェクトの99％がこれを行います。 tslintが後方にあるため、私が取り組んだすべての角度プロジェクトに問題がありました。 あなたの最後のコメントは混乱して近視眼的です。 この信じられないほど有用な提案を受け入れられない/受け入れたくないのであれば、あなたはあまりにも保守的すぎて、そのような重要なプロジェクトについて私たちのために決定を下すことができないと思います。 この問題は、私たちの角度のあるプロジェクトの作業を何年にもわたって困難にしてきました。

@ohjamesトピックにとどまり、個人的な攻撃に向かうのを避けましょう。 誰かが自分のプロジェクトを維持するのに適していないことを示唆することは、OSSに影響を与える方法ではなく、確かに私たち全員がここで主張していることを助けるつもりはありません。

上記のようにネストされた構造に適合しないファイルのオーバーライドが必要なのは理にかなっています。 @giladgrayのコメントは、この問題に関する活動が6か月以上なかったことを考えると、この変更にコミュニティの大きな関心がまだあるかどうかを判断することを目的としていたように思われます。 これは、オープンPR（＃3708）に関する彼のコメントによって具体的に証明されています。

これを追求したい場合は、このブランチを更新して確認できるようにするか、関連性がなくなった場合は閉じてください。 2週間以内にご連絡がない場合は、これを終了します。

@ohjamesコメントを再検討することをお勧めします- 述べたように、個人的な攻撃はここやオープンソースソフトウェアのどこでもあなたを助けるつもりはありません。 誰もが優れた、信頼性が高く、機能が豊富なソフトウェアを作成するために最善を尽くしていますが、人々を攻撃することは決してそれに貢献しません。

このトピックに関する更新はありますか？
@ajafffが要約コメントで提案したアイデアは合理的であり、さまざまなニーズを満たしています。 eslintと同じセマンティクスを使用することは良い方法です。

関連する＃1063についてコメントしたように、私のユースケースは、tslint-microsoft-contribを使用すると、現在、一部のルールでVue単一ファイルコンポーネントを爆撃することです。 これはVueの問題またはTSLintの問題のいずれかである可能性があり、それらのチームは特定の問題の修正に取り掛かるかどうかはわかりません。問題が発生するまで問題のあるルールを無効にすることは、それほど面倒ではない単純な回避策のように思えます。 すべての単一の.vueファイルに同じdisableディレクティブを追加し、ルールのサポートが変更されたときにそれらすべての場所で更新する必要がある場合と比較して。 また、プロジェクトを.vueファイルと.tsファイルに分割することも意味がありません。これは、非常に扱いにくい構造になります。

この機能の導入に賛成です。オーバーライドによってすべてのルールを完全に無効にすることで、＃73のtslintignoreリクエストをきれいに解決できるかもしれません。

{
    "files": "./src/test-data/*.ts",
    "reset": true // Resets tslint.json to {}
}

tslint-microsoft-contribは現在、一部のルールでVue単一ファイルコンポーネントを爆撃しています

ああ😕@ millimoose tslint-microsoft-contribに問題を報告していただけませんか？

@ JoshuaKGoldberg-私はすでに@vuejs / vue-cliでそのバグの詳細なレポートを作成しました。これは最も適切と思われます。 （「複製待ち」とマークされているので、大したことではないと思います。）ここでチャイムを鳴らす動機として言及しました。 これは、進化するエコシステムで収穫できる、そして収穫するようなものです。これは、他の人のバグを実際にハックすることなく、障害を回避するのに十分な柔軟性を備えたツールの議論になるはずです。

この問題に関する更新はありますか？

この問題は現在「提案が必要」としてフラグが立てられていますが、 https： //github.com/palantir/tslint/issues/3447#issuecomment -344020834にすでに提案があると思いますか？

@RoystonS @ajafffの提案では、対処すべきいくつかのルーズエンドについて言及しています。

この動作をTSLintに移植する際には、考慮すべきことがいくつかあります。

• オーバーライドでextendsとlinterOptionsを確実に無効にする必要があります
• おそらくrulesDirectoryも禁止したいと思います
• オーバーライドでrulesとjsRulesを許可しますか、それとも**/*.js?(x)オーバーライドを優先してjsRulesを廃止しますか？

これはかなり重要な機能であるため、先に進む前に、これについてpalantirtech組織の人々からのコンセンサスも必要です。

自分でこれに出くわしただけで、この種の機能に興味を示したいと思います。

最終的に、本番コードに影響を与えるいくつかのリンティングルールを緩和し、それがどのように行われるかを見てみましょう。 ）：

この機能が見たいです

サブスクライブ-これも必要です。

私はこれがとても必要です:(

こっちも一緒！ 私たちはVuejsでtypescriptを使用しており、単体テストファイルはテストディレクトリではなく、コンポーネントのソースコードのいたるところにあります。

この機能をぜひご覧ください。現在、この問題を回避するために、コマンドラインのlintが強調表示するものとは異なるlintingエラーをvscodeが強調表示する、少し不安定な設定を使用しています。

この機能が実装されることはないだろうと私は強く疑っています。tslintは一般的に積極的に保守されていないようです。 @typescript-eslintに切り替えることをお勧めします。これは、eslintプロジェクトとtsプロジェクトの両方から完全にサポートされており、 @ typescript-eslint / eslint-plugin-tslintを使用すると移行がこれまでになく簡単になります。 そして、tslintと対応するeslintルール/他の選択肢を備えた互換性のあるテーブルがあります。 Eslintのセットアップは高度にカスタマイズ可能であるため、tslintに固執する意味はありません。

gitリポジトリが.gitIgnore ...内のファイルに使用する概念をtsLintルールに適用することを提案します。 特定のサブディレクトリをリントするときの、オーバーライドファイルとともに、リンターへのコンテキストとしての現在の階層位置の使用。 次に、任意のディレクトリレベルで任意の構成を含めたり除外したり、設定したりできます。

例えば
tslint構成はルートに配置され、ソースコード構造の特定のレベルで、別の動作が必要になります。そのサブディレクトリのルートにある拡張子tslintファイルでオーバーライドするだけです。

@redevill testフォルダにテストを書くのに役立ちます。 ただし、コンポーネント/サービスの同じフォルダーでのsomething.test.tsとしての書き込みテストは1つではありません。

同意しました-ただし、マイナーな変更があります:(テンプレートジェネレーター（CLIスタイル）で自動化できます）
MyComponentDir
--- MyComponentTestsDir
------ tslint.test.json
------ something.test.ts
--- mycomponent.component.css
--- mycomponent.component.html
--- mycomponent.component.ts

アイデアはまだ機能する可能性があります。

この提案の大ファン。 はい、お願いします！ 私の好みはオーバーライドの概念です。

ところで、tslintの非推奨の発表を考えると、この段階でこのような大きな変更が行われることは_本当に_想像できません。私のチームは、すでにルールごと+ファイルごとのオーバーライド機能を備えたeslintに移行しています。

前述の発表： https ：

@RoystonSは基本的に正しいので、この時点ではこのような大きな機能はtslintに追加されません。 ＃4534を参照

Angularプロジェクトを使用します。 オーバーライドの概念が必要です。 そうでなければ、管理するのは苦痛です