tslint folders
v4.1.5
TSLINTを使用して、TypeScriptプロジェクトのパッケージとフォルダー間の無効なインポートをチェックします。
パッケージアーキテクチャの自動検証とドキュメント（ tslint-folders-diagrams経由）。
TSLINTフォルダーは安定しており、CIビルドと少なくとも1つの主要な製品の開発ボックス（Linux、Mac、Windows）で毎日使用されています。
次のような「愚かな」ミスのためにレビューを手動でコードするのに費やした時間を節約します。
file-name-casingでは、1つのスタイルのみが可能になります） バージョン化にはSemverを使用しています。利用可能なバージョンについては、リリースを参照してください。
yarn add tslint-folders
tslint.jsonを編集して、tslint foldersを指すエントリ"rulesDirectory"を用意します。
通常、これは次のようになります。
"rulesDirectory": "./node_modules/tslint-folders/dist/lib/"
例については、tslint.tslintfolders.jsonを参照してください。
tslintルールは有効になり、 tslint.jsonで構成されています。
tslint.tslint-folders.jsonのtsf-folders-imports-between-packagesのセクションまたは例については、セクションを参照してください。
オプションで、 tslint.tslint-folders.jsonのように、tslintfolders構成を別のファイルに分割できます。ファイルを参照するには、このコードをtslint.jsonに追加します。
"extends": "./tslint.tslint-folders.json"
TSLINTが既に整っていると仮定すると、TSLINTによって予期しないインポート（または無効なテスト）がフラグを立てることがわかります。これは、コマンドラインで、または視覚コードなどのエディターで通常どおり機能する必要があります（エディターを更新する必要がある場合があります）。
tslint-folders-diagramsを参照してください
図は、コードの検証に使用される同じ構成から自動的に生成できます。
詳細については、tslint-folders-diagramsを参照してください。
現在のカスタムルールの概要を次に示します。
| ルールID | 説明 |
|---|---|
| TSFフォルダー障害のあるテスト | 障害のある単体テスト、テストスイート、または統合テストを検出します。 |
| TSFフォルダーファイル名 | ファイル名のケーシングを検証します。標準のfile-name-casingと同様に、複数の許可されたケーシングをサポートし、無効な文字（スペースやコンマなど）でファイル名を許可します。 |
| TSF-folders-import-from-disallowedフォルダー | node_modulesのような標準以外のフォルダーからインポートを検出します |
| TSFフォルダー - インポート - パッケージ | 「より高いレベル」のパッケージからインポートを検出します。たとえば、「エリア」パッケージ内にあるときに、アプリケーション「シェル」パッケージからインポートします。これが主なカスタムルールです。また、このパッケージ名を使用して（相対パスの代わりに）パッケージにインポートがある場合も検出できます。 |
| TSF-folders-test-with-breakpoint | 統合テストにbrowser.debug()のようなブレークポイントがある場合を検出します |
| サイト | URL |
|---|---|
| ソースコード（github） | https://github.com/mrseanryan/tslintfolders |
| githubページ | https://mrseanryan.github.io/tslint-folders/ |
| npm | https://www.npmjs.com/package/tslint-folders |
すべてのルールでは、同じプレフィックスtsf-folders-を使用します。
カスタムルールが関係していることを開発者に明確にするために、ルールからのすべてのメッセージにはルールIDも含まれます。
これらのルールの一部は、標準のtslint構成に置き換えることができます。ただし、カスタムルールを使用すると、開発者が何を修正するか（またはそのコードを無効にするルール）を知るのに役立つより明確なメッセージが得られます。
いくつかのルールは、厳密に「フォルダー」に関するものではありませんが、ここには役立つと思われるため、ここに含まれています。
詳細と例については、ユニットテストをご覧ください
TSLINTフォルダーのソースコードに取り組むには、いくつかのスクリプトがあります。
| 指示 | 説明 |
|---|---|
| 糸ビルド | ルールを「DIST」フォルダーに構築し、そこから実行できます。 |
| 糸糸状 | ルールのソースコードを並べます。 |
| 糸のスタート | コードを構築、テスト、リントします。 |
| 糸検査 | 仕様ファイル（*.lint）に対するルールをテストします |
| 糸テスト1 | 仕様ファイルに対して単一のルールをテストする（*.lint） |
ルールtsf-folders-imports-between-packagesの単体テストはこちらです。
ユニットテストでは、テストデータを使用して、かなり典型的なWebサイトのパッケージ境界を確認します。
一致する構成は、tslint.tslintfolders.jsonで見ることができます
テストデータは、複数のパッケージを使用するWebサイトに基づいています。
| パッケージ名 | 説明 |
|---|---|
| シェル | アプリケーションシェル - これはトップレベルのパッケージであり、他のパッケージからインポートできます。 |
| dodo-area | シェル内でホストされているウェブサイトの「TODOアプリ」領域。シェルまたは他の「エリア」パッケージからインポートしないでください。 |
| dodo-contact | シェル内でホストされているウェブサイトの「連絡先情報」領域。シェルまたは他の「エリア」パッケージからインポートしないでください。 |
| グリッドパッケージ | エリアパッケージで使用されるUIグリッド。他の認識されたパッケージをインポートしないでください。 |
| utils | シェルパッケージとエリアパッケージで使用される「UTILS」パッケージ。他の認識されたパッケージをインポートしないでください。 |
検証の例：「シェル」は「todo-area」からインポートできるはずですが、その逆ではありません（シェルはより高いレベルの抽象化であり、2ウェイの依存関係を避けたい）。
TSLINTフォルダーは、パッケージのサブフォルダー間のインポートを検証することもできます。
テストデータ「TODO-AREA」パッケージは、「コンポーネント」や「モデル」などのかなり典型的なサブフォルダーで構成されています。 tslint.tslintfolders.jsonは、これらのフォルダー間のインポートを確認するように構成されています。
| サブフォルダー名 | 説明 |
|---|---|
| コンポーネント | UIコンポーネントのトップレベルフォルダー。他の認識されたフォルダーのいずれかからインポートできます。 |
| ViewModels | UIコンポーネントで使用されるビューモデルのフォルダー。モデルまたはUTILからのみインポートできます。 |
| モデル | ビューモデルで使用されるモデルのフォルダー。 utilsからのみインポートできます。 |
| utils | 「Utils」フォルダー。他の認識されたフォルダーをインポートしないでください。 |
検証の例：「コンポーネント」は「モデル」からインポートできるはずですが、その逆ではありません（コンポーネントはより高いレベルの抽象化であり、2ウェイの依存関係を避けたい）。
貢献しているreadmeを参照してください。
このプロジェクトは、優れたSeeder Project TypeScript-Library-Starterに基づいています。
このプロジェクトは、大規模なタイプスクリプトコードベースで同様のコーディングの問題を繰り返し修正する必要がないように開始されました。
こちらをご覧ください
それはほとんどそれです。これが役立つかどうか、またはどのように改善できるかを教えてください！
ショーン・ライアンによるオリジナル作品-Sean.Ryan氏（gmail.com）
このプロジェクトはMITライセンスに基づいてライセンスされています - 詳細については、ライセンスファイルを参照してください
