サーチ…
前書き
Meteor 1.3のリリース以前は、Meteor開発者はMeteor.jsのファイル依存関係やグローバル変数の扱いに不満を抱いていました。これに対応して、Meteorはプロジェクトの依存関係システムをより合理化するために、プロジェクト構造の新しい基準を設定しました。このトピックでは、標準化されたプロジェクトの構造とその背後にある原則について説明します。
備考
クライアント
クライアントディレクトリ内のすべてのコードは、クライアント側またはWebブラウザでのみ実行されます。
クライアント/互換性
互換性ディレクトリには、jQueryライブラリなどのレガシーコードまたはサードパーティコードが含まれています。
lib
libディレクトリーは、Meteorプロジェクトの他のディレクトリーの前にロードされ、サーバーとクライアントの両方にロードされます。これは、データモデル、同型ライブラリ、およびビジネスロジックを定義するのに好ましい場所です。
輸入
importsディレクトリは、サーバー上のディレクトリであり、クライアントバンドルがクライアントに送られる前にのみ、サーバーとクライアントの両方で使用できます。
パッケージ
packagesディレクトリは、ローカル開発中にカスタムパッケージが格納されるディレクトリです。 meteor add package:nameを追加するためにmeteor add package:name標準コマンドmeteor add package:nameを使用する場合、Meteorはローカルpackageがpackage.jsファイルに対応する記述名を持っているかどうかを最初に調べます。そうでない場合は、いつものように雰囲気をポーリングします。
プライベート
プライベートディレクトリには、Webサーバー上でのみ使用できる静的ファイルが含まれています。
パブリック
パブリックディレクトリには、アプリケーションクライアントでのみ使用可能な静的ファイルが含まれています。これには、ブランド資産などが含まれます。
サーバ
サーバーディレクトリには、サーバー側の資産が含まれています。これには、認証ロジック、メソッド、およびセキュリティを考慮する必要のあるその他のコードが含まれます。
テスト
テストディレクトリは、アプリケーションがバンドルされてデプロイされているとき、デフォルトでは省略されています。
Richard Silvertonの提案によれば、バージョン管理下の流星プロジェクトディレクトリだけでなく、その親ディレクトリも置くのが便利です。
そうすれば、バージョン管理の下にファイルを流通させずにファイルを扱うことができます。
クラシックディレクトリ構造
Meteorツールには、特定のロジックでハードコードされたディレクトリがいくつかあることが、アプリを構造化する際にまず知る必要があることです。非常に基本的なレベルでは、以下のディレクトリがMeteor社のバンドラに「焼き付けられる」。
client/ # client application code
client/compatibility/ # legacy 3rd party javascript libraries
imports/ # for lazy loading feature
lib/ # any common code for client/server.
packages/ # place for all your atmosphere packages
private/ # static files that only the server knows about
public/ # static files that are available to the client
server/ # server code
tests/ # unit test files (won't be loaded on client or server)
参照ページ： 流星ガイド>特別なディレクトリ
パッケージのみのディレクトリ構造
多くの人は最終的に複数のアプリケーションをサポートし、アプリケーション間でコードを共有したいと考えています。これは、マイクロサービスアーキテクチャとすべてのパッケージアプリの概念につながります。基本的に、古典的なディレクトリ構造全体のコードは、パッケージにリファクタリングされます。
パッケージにはディレクトリのハードコーディングされたロジックはありませんが、パッケージを作成する際には古典的なディレクトリ構造を使用することをお勧めします。これにより、フィーチャがアプリでプロトタイプ化され、公開されて共有されるパッケージに抽出されるので、自然のリファクタリングパスが作成されます。ディレクトリ名は共有されているので、チームメンバー間の混乱は少なくなります。
client/ # client application code
packages/ # place for all your atmosphere packages
packages/foo/client # client application code
packages/foo/lib # any common code for client/server
packages/foo/server # server code
packages/foo/tests # tests
server/ # server code
インポート/モジュールのディレクトリ構造
Meteorの最新バージョンは、 ecmascript 、別名ES6またはES2015をサポートしています。パッケージの代わりに、Javascriptはパッケージ文だけのアプリケーションの必要性を置き換えるimport文とモジュールをサポートするようになりました。最新のディレクトリ構造はパッケージのみの構造に似ていますが、 /packagesではなく/importsディレクトリを使用し/packages 。
imports #
imports/api # isomorphic methods
imports/lib # any common code for client/server
imports/client # client application code
imports/server # server code
混合モードディレクトリ構造
そして、もちろん、これらのアプローチを混在させて、アプリケーション固有のコードと一緒にパッケージとインポートの両方を使用することもできます。ミックスモードの構造は、3つの状況で最も一般的です：franken-appは、全体的な戦略なしでちょっとしたものをここから先に引っ張ってくるものです。クラシックまたはパッケージのみの構造からインポート/モジュール構造に積極的にリファクタリングされているアプリです。
client/ # client application code
client/compatibility/ # legacy 3rd party javascript libraries
imports #
imports/api # isomorphic methods
imports/lib # any common code for client/server
imports/client # client application code
imports/server # server code
lib/ # any common code for client/server.
packages/ # place for all your atmosphere packages
packages/foo/client # client application code
packages/foo/lib # any common code for client/server
packages/foo/server # server code
packages/foo/tests # tests
private/ # static files that only the server knows about
public/ # static files that are available to the client
server/ # server code
tests/ # unit test files (won't be loaded on client or server)
ディレクトリ読み込み順序
HTMLテンプレートファイルは常に他のものより先に読み込まれます
mainで始まるファイル。最後にロードされる
lib /ディレクトリ内のファイルは次にロードされます
より深いパスのファイルが次に読み込まれます
ファイルはパス全体のアルファベット順にロードされます
参照ページ： 流星ガイド>アプリケーションの構造>デフォルトのファイル読み込み順序
