wotan

Fimbullinterプロジェクト

Pluggable TypeScriptとJavaScriptリナー

利用可能なパッケージ

wotan

優れたビルトインルールのセットを備えたメインリナーランタイム。独自のルール、プロセッサ、フォーマッタ、共有可能な構成、プラグインモジュールでカスタマイズできます。

利用可能なルール、構成、および使用状況の詳細な説明については、ドキュメントを参照してください。

ヴェ

VUEシングルファイルコンポーネント（SFC）の公式プロセッサ。糸くずのために*.vueファイルからスクリプトコンテンツを抽出します。

ハイムダル

互換性レイヤーWOTANランタイム内でTSLINTルールとフォーマッタを使用できるようにします。

ヴァルティール

Wotanをtslintのように動作させます。変更せずに既存のtslint.jsonを再利用してください。

ビフロスト

Tslintルールとフォーマッタの著者は、Wotan内で使用するためのパッケージを提供できます。 Bifröstを使用するルールとフォーマッタは、正しく機能するためにHeimdallを必要としません。

イミール

カスタムルールとプラグインの著者にコアタイプを提供します。

ミミール

すべてのコアルール、フォーマッタ、構成プリセットが含まれています。

Mithotyn

TypeScript用のLanguageserviceプラグイン。入力中はリアルタイムの編集者の糸くずを提供します。

さらなるドキュメント

• TypeScriptのAPIの理解
• ルールを書く
• テストルール
• ローカルルールの使用
• 共有可能な構成の書き込み
• APIを使用します

レシピ

• TSLINTルールを備えたVUEファイルを癒します
• tslint --type-checkの交換
• 未使用の変数を検出します

これは何ですか？

それらの名前はどうしたの？

北欧神話：

Fimbullinterは、Ragnarökの出来事に先行する3年間のひどい冬であるFimbulwinterから来ています。 「fimbul」は「偉大な」を意味します。「リナー」は、特定のコーディングパターンを検出および警告するツールです。

ウォタンは、オーディンの多くの名前であるオールファーザーの1つです。また、Woden、Wodan、Wensleyなどの名前で彼を知っているかもしれません。Wodenは犠牲の神であり、血に飢えた残酷です。彼は常に知恵を求めて努力しています。彼の王位から、彼は9つの世界のすべてが起こっているのを見ることができます。

ヴェは、巨大なイミールを一緒に殺し、彼の体から9つの世界を創造した3人のウォーデン、ヴィリ、ヴェの中で最年少です。

最初の人間のカップル、尋ねて、エンブラに、オーディンは魂と命を与えました。ヴィリは機知（知性）と感覚を与えました。そして、ヴェは表情（外観、表情）、スピーチ、聴覚、視覚を与えました。

燃えているレインボーブリッジが天国と出会う場所にあるハイムダル（ハイムダルとも呼ばれます）は、ラグナロクの発症を監視し続けています。

ビフロストは、人間の世界と神の領域をつなぐ燃える虹の橋です。

「ヴァル」（死者、戦いで殺された）と「ティル」（神）のヴァルティールは、殺された人の神を意味し、オーディンを参照するためにしばしば使用されます。

イミールは、全世界が創造された体の巨人です。彼はすべてのヨットナーの祖先です。

Mímir （「賢明な人、賢明な人」）は、彼の知識と知恵で有名です。神オーディンはミミールの頭の周りに持ち込み、それは彼に秘密の知識と助言を暗唱します。

Mithotyn （実際には「Mitoðinn」、「Fate of Fateのディスペンサー」を意味する）は、何もなかったルールを導入します。外国の土地への旅行中にオーディンの場所を埋めます。

なぜさらに別のリナー？

これは、問題があることが判明した他のリナーの設計上の決定を避けようとします。

• ルール名に応じてルール名をプレフィックスすることにより、名前の競合を避けてください。
  • TSLINTは、すべてのルールをグローバルネームスペースに配置し、利用可能なすべてのルールディレクトリでそれらを検索します。ディレクトリの順序は重要ですが、コアルールオーバーライドが優先されます。
  • ESLINTでは、CLIフラグとしてローカルルールディレクトリを許可します。そのディレクトリのルールは、コアルールをオーバーライドできます。
• 構成ファイルの依存関係は、そのファイルに対して解決されます。
  • Tslintはすでにそれをしています。
  • Eslintはそれをサポートしていません。
• 共有可能な構成とプラグインを区別しません。実際、どちらもオプションでルールディレクトリ、設定、ルール、プロセッサを提供できる拡張可能な構成です。
  • TSLINTを使用すると、 extendsとrulesDirectory選択できます。パッケージのルールディレクトリは実装の詳細であり、ユーザーの構成の一部であるべきではありません。
  • Eslintは、構成とプラグインをかなり異なるものに処理します。実際、彼らはプラグインを支持して共有可能な構成を非難しようとしました。
• スタートアップ時間を短縮するためのルールの怠zyなロード。
  • Tslintはすでにそれをしています。
  • Eslintは、プラグインがすでにロードされたオブジェクトとしてルールを提供することを期待しています。大きなパッケージのいくつかのルールしか使用しない場合、それは多くのオーバーヘッドを引き起こします。
• ファイルシステムのアクセスと構成のキャッシュ。キャッシュはDIサービスであるため、APIユーザーは必要に応じてキャッシュをクリアできます。
• 最初からプロセッサのサポート。 *.vueファイルなどの糸くずを有効にします。
• 構成を備えたルールのエイリアス。 ESLINTのno-resticted-syntaxのようなルールを、各構成オプションの明確な名前のルールとして扱うために使用できます。
• API全体にDIコンテナが搭載されています。そのため、別のサービスを簡単に注入できます。 CLIを介してプラグインを使用してさまざまなサービスを注入することもできます。
• CLIデフォルトとプラグイン構成の「グローバル」構成ファイル（ .wotanrc.yaml以外）：. .fimbullinter.yaml 。このファイルはエディタープラグインでも使用できますので、共通構成を複製する必要はありません。
  • Eslintはそのようなファイルを持っておらず、将来のファイルを追加することを拒否しました。 standardやxoなどのツールは、CLIのデフォルトでこのような構成ファイルを作成する必要がある場合に存在する必要はありません。
  • tslint Startetは、混乱したユーザーにつながるtslint.jsonに詰めます。
• 未使用で冗長な報告を--report-useless-directivesとのコメント（またはその部分）を無効にします。
  • Eslintは、未使用の無効化コメントのみを報告しています。完全に使用されていないコメントのみを報告します。冗長なコメントは報告されておらず、存在しないルールに対するコメントを有効にします。
  • Tslintはそれをサポートしていません。

tslintの違い

• プラグインまたは共有可能な構成を拡張するには、 extends: plugin-nameを使用します。名前は、構成ファイルに対するNodeのモジュール解像度アルゴリズムに従って解決されます。
• プロジェクト内で維持されているルールを使用するには、 rulesDirectory: {"my-prefix": "./path/to/rules"}を使用し、 my-prefix/rule-one: "error"としてそれらを構成します。ルールディレクトリは、構成ファイルに関連するパスです。
• オーバーライド：1つ以上のオーバーライドを指定することにより、主な補強材をオーバーライドできます。ファイル名がオーバーライドのグローブパターンと一致する場合、そのオーバーライドによって提供されるすべての設定が適用されます。オーバーライドは順番に処理され、後でオーバーライド前回のオーバーライドからのオーバーライド設定。
  • パターンは、指定されている構成ファイルに関連して一致します。
  • スラッシュのないパターンは、各ファイルのベースネームとのみ一致します。
  • 一致を現在のディレクトリに制限するには、パターンに./プレフィックスします。
  • 否定されたパターンを使用して、前のパターンの一致から差し引くことができます。
• linterOptions.exclude > exclude
  • 除外は、構成を拡張するときにオーバーライドされません。
  • パターンマッチングは、オーバーライドと同じルールに従います（上記参照）。
• 構成ファイルのJSON5サポート。
• ルールとプロセッサがピックアップできるルールに依存しない設定。
• プロセッサは、 --projectをサポートします。
• エイリアス、上記を参照してください
• 修正への正気で安全なアプローチ：
  • 構文エラーを備えたファイルを修正しません。
  • コードの破壊を防ぐために、重複する交換を除外します。
  • 次の反復で競合する変更を適用するために、ファイルごとに構成可能な数の反復を実行します。
  • 修正が構文エラーが導入されると停止します。
  • --projectで修正しても、プログラム全体がゼロから作成されることはないため、非常に高速になります。
• テスト
  • テストはJSONファイルで構成されており、CLIを使用して指定できるすべてを構成できます
  • テストファイルにはエラーマークアップが含まれていません。これにより、構文エラーが回避され、メンテナンスが容易になります。 Lintの結果と固定コンテンツは、別々のベースラインファイルに保存されます。
  • 同じコードを異なる設定でテストできます。
• タイプスクリプトプロジェクトの参照をサポートします。
• .fimbullinter.yamlのCLIオプションのデフォルト値をロードします。
• 未チェックのJavaScriptファイルでタイプ情報を使用しません（ // @ts-nocheckまたは"checkJs": false ）。
• 未使用で冗長な報告を報告し、コメントを--report-useless-directivesにして無効にします。

サポートされている環境

このプロジェクトは、node.jsのアクティブにサポートされているすべてのバージョンで実行されます。

このプロジェクトは、TypeScriptの最新の3つの安定したバージョンを正式にサポートしています。書いている時点では、これは3.0-3.2です。 TypeScriptの夜間ビルド（ typescript@next ）で動作するはずですが、保証はありません。

カスタムルールは、少なくともES6を使用して、ネイティブクラスをサポートする必要があります。それ以外の場合は、パッケージのいずれかからエクスポートされたクラスを拡張しようとすると、問題が発生します。

セマンティックバージョン（Semverポリシー）

ショ和以下のポリシーは、まだ1.xおよび次のリリースにのみ適用されます。 0.x範囲のすべてのリリースは実験的と見なされます。非推奨なしにAPIの変更を破ることができます。

理論的には、ルールへのすべての変更はユーザーを破ることができ、壊れた変化と見なされる可能性があります。バグ修正ごとに新しいメジャーバージョンをリリースしないようにするために、以下に概説するように、わずかに異なるガイドラインがあります。

プレレリース（毎晩ビルド）

• 安定することが保証されていません
• npmのnextようにタグ付けされているので、 @fimbul/wotan@nextをインストールできます
• 次のリリースを目的とした最新の変更が含まれています
  • x.0.0-dev*次のメジャーバージョンの破壊を含むすべての変更が含まれています
  • xy0-dev*には、次のマイナーバージョンのすべての変更が含まれています
  • パッチバージョンにはプレレリーズはありません

パッチリリース

• 修正クラッシュ
• 回帰を修正します
• ユーザーに直面している動作を変更しない内部機能のリファクタリング

マイナーリリース

• 新しいルール、ルールオプション、フォーマッタ、プロセッサ、APIを追加します
• ルールは、新しい調査結果につながる可能性のある新しいチェックを追加できます
• wotan:latestの新しいルールとオプションが有効になっています
• ルールは、検索メッセージを変更できます
• 人間の消費を目的としたフォーマッタ（例： stylish ）は出力を変更できます
• ルール、ルールオプション、フォーマッタ、プロセッサ、APIを非推奨することができます
• 新しい構成オプションを構成ファイルに追加できます

主要なリリース

• APIの破壊の変更が含まれています
• 以前に非推奨のルール、オプション、フォーマッタなどを削除します。
• マシン消費を目的としたフォーマッタ（ jsonまたはtapなど）は出力を変更できます
• wotan:recommended 、 wotan:latestコンテンツに更新されます

リリーススケジュール

現在、固定リリーススケジュールはありません。マスターに変更がある場合、毎晩毎晩公開されます。パッチリリースは、バグが特定されて固定されるとすぐに公開されます。マスターに変更がある場合、マイナーリリースは毎週1〜2週間公開されます。十分な壊れた変化が積み重なると、主要なリリースが公開されます。

ライセンス

Apache-2.0©Klaus Meinhardt