ひどいインポートクラーケン-ES6モジュールを使用して狂わない方法

グローバルスコープ（TypeScriptの名前空間）はもはやクールではありません。 長い間モジュール（特にES6モジュール）の利点をリストすることは可能ですが、私にとって決定的なことは、SystemJSを使用してソースコードとロールアップを動的にロードし、バンドルを構築できることでした。

ただし、ES6モジュールを実装するときに最初に出てきたのは、非常に多くのインポート式で、内部には非常に多くのポイントがあります。

import { FieldGroup } from "../../../Common/Components/FieldGroup/FieldGroup"; 

触手はどこから成長しますか？

ES6仕様ではこれについてはあまり言及されておらず、モジュールへのパスは「ローダー固有」であるというフレーズを振っています。 つまり、SystemJSを使用する場合、パスの形式によってSystemJSが決まり、Webpackの場合はWebpackが決まります。 ブートローダー仕様の作業は進行中ですが、watwgリポジトリのメインページに次のように記載されています 。

この仕様は現在、潜在的に大規模な再設計が行われており（＃147および＃149を参照）、実装の準備ができていません。

これまでのローダー間の合意は、「./」で始まるパスは、現在のモジュールが置かれているディレクトリと同じディレクトリを探す必要があるということだけです。 それぞれ二重ドット「../」を使用すると、1レベル上に移動して親ディレクトリを確認できます。 同時に、最も単純なプロジェクトであっても、あらゆる意味でひどい3〜4個のダブルポイント「../../../」を含むパスを取得するのは非常に簡単です。

仕様がないため、今では誰でもできる人の問題を解決しています。 通常、この目的のために、いくつかのルートフォルダーが設定され、すべてのパスはそれに関連しています。 たとえば、babelコミュニティはpluginを考案しましたが、webpackはresolution.root設定をサポートしています。

 import { BasicEvent } from '~/Common/Utils/Events/BasicEvent' 

ただし、ルートフォルダーを構成しても、各ファイルの先頭にあるimport-expressionsの巨大なヘッダーからは保存されません。 良いマナーは、コードを可能な限り小さなモジュールに分割するように指示します。これは問題の原因です（オタクはコードをよりよく分解する必要があると言いますが、現実の世界は常に望んでいるものではありません）。

これは特に悲しいことです。特定のモジュールをインポートするたびに、ファイルシステム内のこのモジュールの場所への固定バインディングを作成します。 したがって、1）少なくとも、各モジュールの場所を正確に覚えておく必要があります2）リファクタリング（たとえば、ファイルの名前を変更する）を行う場合は、多くの苦痛が待っています。

さて、VisualStudioでTypeScriptを使用するときに遭遇する最後の問題は、インポートされた文字のJSXリンティングと同様に、構文の強調表示がそこで機能しないことです。 例：

 import { FieldGroup } from "../../Components/FieldGroup/FieldGroup"; import { BasicEvent } from "../../Common/Utils/Events/BasicEvent' ... var event = new BasicEvent(); // BasicEvent  VisualStudio     ... render() { // JSX  FieldGroup  VisualStudio   (   ), //  intellicese  , .. FieldGroup   return <FieldGroup name="blabla" />; } 

マイクロソフトでは、明らかに、彼らは問題を解決するために急いでいない（ 問題1 、 問題2 ）。

魔法のパッケージはみんなを救う

問題の解決策は、ランダムに相互接続された個々のモジュールのアイデアを放棄し、「モジュールパッケージ」のようなものを使い始めることです。 そのような解決策がこのコンテキストのどこかに既に公開されているかどうかはわかりません （UPD： gogolorはAngularにバレルと呼ばれるドックがあることを提案しました）が、アイデア自体は新しいものではありません。 たとえば、C＃にはコードを含む個別のファイルもありますが、同時にこれらのファイルは「アセンブリ」（dll）に収集されます。これは、他のアセンブリへのリンクを既に明示的に宣言します。

次のプロジェクト構造（管理パネルの実際のプロジェクトのスクリーンショット）があると想像してください。

AssignmentTemplatSettings.tsxファイルからBasicEvent.tsに到達するには、次のように記述する必要があります。

 import { BasicEvent } from '../../Common/Utils/Events/BasicEvent'; 

これは、上で説明したすべての理由でひどいです。 しかし、プロジェクトの構造を見ると、すべてのモジュールが自然にフォルダーに分散されていることに気付くのは簡単です。 プロジェクトが複雑になるほど、フォルダ構造は分岐します。 すべての開発者の命を命じたいという欲求、そしておそらく、あなたのプロジェクトでも同様のことが起こります。

良いニュースは、ES6モジュールを使用すると、このフォルダー構造を、デスクトップの世界のdllを非常に連想させる「パッケージ」構造に変換できることです。 各フォルダーをパッケージにすることができ（たとえば、Common / Utils / Eventsはネストされたパッケージになります）、より大きな単位（Common / Utilsのみ）に制限できます。 モジュールの各パッケージについて、それが依存するパッケージと「公開する」ものが明確に示されます。 これらの依存関係はすべて1つの時点で収集されるため、パッケージモジュールは他のパッケージのモジュールの場所について何も知りません。 この場合、相対パスのポイント（ "../../"）の数は、1つのパッケージ内のフォルダーのネストに過ぎず、インポート式の数は1つに削減されます。

実装

フォルダーをパッケージに変換するには、2つのファイルを追加するだけです-インポートとエクスポート。 最初のファイルでは、このパッケージのモジュールに必要なものをすべてインポートおよび再エクスポートします。 2番目のファイルには、パッケージが他のパッケージへのインポートに使用可能にするすべてのエクスポートが含まれています。

輸出販売

Eventsフォルダーからパッケージを作成してみましょう。 BasicEventとSimpleEventの2つのクラスを公開します。 次に、@ EventsExports.tsファイルは次のようになります。

 export * from "./BasicEvent"; export * from "./SimpleEvent"; 

ファイル名に「@」が含まれていると、他のパッケージファイル間で失われず、常に最上位になります。 ここでは他のパッケージの何も必要ないので、ここではインポートファイルをまだ実行していません。 次に、親フォルダーUtilsおよびCommonをパッケージに変換します。 たとえば、@ UtilsExports.tsには次が含まれます。

 import * as Events from "./Events/@EventsExports"; import * as ModalWindow from "./ModalWindow/@ModalWindowExports"; import * as Other from "./Other/@OtherExports"; import * as RequestManager from "./RequestManager/@RequestManagerExports"; import * as ServiceUtils from "./ServiceUtils/@ServiceUtilsExports"; export { Events, ModalWindow, RequestManager, ServiceUtils }; 

Utilsフォルダーに直接あったCachingLoaderモジュールおよびその他のモジュールは、ここにはリストされていません。 これはこのアプローチの制限であり、他のパッケージをエクスポートするパッケージにモジュールを含めることはできません。 したがって、これらのファイルをすべて他の子パッケージに移動する必要がありました。 インポートファイルの内容は、後で確認されます。

同様に@ CommonExports.tsを実行します。

 import * as Components from "./Components/@ComponentsExports"; import * as Extensibility from "./Extensibility/@ExtensibilityExports"; import * as Models from "./Models/@ModelsExports"; import * as Services from "./Services/@ServicesExports"; import * as Utils from "./Utils/@UtilsExports"; export { Components, Extensibility, Models, Services, Utils }; 

インポートを実現

それでは、タブパッケージに移りましょう。 明らかに、Commonパッケージの多くのクラスが必要になります。 したがって、その@ TabsImports.tsファイルは次のようになります。

 import * as Common from "../Common/@CommonExports"; export { Common }; 

このパッケージのAssignmentTemplatesSettings.tsxモジュールで、次のように記述します。

 import { Common } from "../@TabsImports"; // -  using       var Events = Common.Utils.Events; //   BasicEvent   Common/Utils/Events/BasicEvent.ts var basicEvent = new Events.BasicEvent(); 

ご覧のとおり、BasicEventファイルへのフルパスを指定する代わりに、どのパッケージにあるかを示します。 特に素晴らしいのは、Events.BasicEventを書くとき、VisualStudioでの構文の強調表示とJSXリンティングが素晴らしいことです！

タブパッケージがイベントパッケージのみを必要とする場合、次のようにTabsImports.tsを書き換えることができます。

 import * as Common from "../Common/@CommonExports"; var Events = Common.Utils.Events; export { Events }; 

または：

 import * as Events from "../Common/Utils/@EventsExports"; export { Events }; 

後者の場合、再びパスにアタッチされますが、このバインディングはパッケージレベルにあるため、リファクタリングするときの痛みは各モジュールにあるときよりもはるかに少なくなります。 インポートされるコードの量を減らしたため、モジュールのコードを実行する前にローダーが準備する必要のあるファイルの数を制限しました（たとえば、これはバンドルを遅延ロードされる複数の部分に分割する場合に関係します）。

パッケージ内のモジュールの相互接続

パッケージ内のモジュール間の通信はそれほどひどい問題ではありません。 それらはすべて近くにあります。 ただし、いくつかの理由により、同じメカニズムを使用して現在のパッケージのモジュールをインポートする必要がある場合があります。 エクスポートファイルの使用は機能しません。 定義上、パッケージのすべての内容を含めるべきではありません。 ただし、これを使用して3番目の内部ユーティリティファイルを作成できます。

 export * from "./@EventsExports"; // -   export * from "./SomeInternalEventImpl"; //    export * from "./SomeAnotherInternalEventImpl 

したがって、その後、パッケージ内のどこでもこのファイルを使用できます。

 import * as Events from "./@EventsInternals"; let eventImpl = new Events.SomeInternalEventImpl(); 

仕様では循環依存関係が許可されているため、内部のインポートに問題はありません。 少なくともSystemJSはそのような状況を正しく処理します。

結果

1. インポートパス内の恐ろしいポイント "../../../"を取り除きましたが、絶対パスに頼らず、相対的な柔軟性を維持しました。
2. 使用した各モジュールを個別にインポートし、各ファイルに巨大なインポートヘッダーを作成する必要性を取り除きました。 代わりに、パッケージのインポートファイルから必要なパッケージを1回インポートします。
3. VisualStudioで構文の強調表示とJSXリンティングを返しました。
4. インポート時にはファイル名ではなく変数（パッケージ）を使用するため、TypeScript環境でのリファクタリングは基本になります。 パッケージの名前は自動的に変更され、find-all-referencesなどが機能します。
5. モジュール間の依存関係は順序付けられており、特別なファイルに集中していますが、特別なファイルはそれほど多くありません。 TypeScriptがなくても、このようなコードのリファクタリングははるかに簡単です。
6. 必要に応じて、パッケージは多少分離されており、その依存関係がすべて明確に登録されているため、任意のパッケージを個別のプロジェクトに簡単に分離できます。 パッケージへの分割により、開発者はアプリケーションをより適切に構成する必要があります。
7. 頻繁に使用されるパッケージの場合、ブートローダーでエイリアスを設定し、パスを指定せずに名前で単純にインポートできます。

欠点の-常に更新する必要がある追加のインポート/エクスポートファイルがあります。 原則として、そのようなファイルのコンパイルはそれほど複雑ではないgulpタスクで自動化できます;主なことは、パッケージのエクスポートされたモジュールと内部モジュールを区別する方法に関する規則を考え出すことです。 まあ、また欠点として-インポートされた文字にアクセスするときは、パッケージ名（BasicEvnetの代わりにEvents.BasicEvent）を追加する必要があります。 しかし、見返りに得られるものを考えると、これは和解できると思います。

UPD： justborisは、エクスポートファイルをindex.tsと簡単に呼ぶことができることに気付きました。 多くのビルダーとIDEは、それをディレクトリ内のデフォルトファイルと見なします。
UPD： dzigoroは、WebStormがインポート宣言の自動追加とリファクタリング中の更新をサポートしていることを指摘しました。