Node.js_node.jsのモジュールの仕組みの勉強メモ

JavaScript が誕生して以来、JavaScript をプログラミング言語とみなした人は誰もいませんでした。 Web 1.0 時代には、このスクリプト言語は主にフォーム検証と Web ページの特殊効果に使用されていました。 JS が広く評価されるようになったのは、フロントエンド エンジニアが JS を使用して Web ページのユーザー エクスペリエンスを大幅に向上させた Web 2.0 の時代になってからです。 JS の人気が高まるにつれて、ツール ライブラリ、コンポーネント ライブラリ、フロントエンド フレームワーク、およびフロントエンド アプリケーションにおおまかな変更が加えられてきました。 Javascript には本質的にモジュールという機能が 1 つ欠けていますが、CommonJS 仕様の登場によってこの欠点が補われています。この記事ではCommonJSの仕様とNodeのモジュールの仕組みを紹介します。

他の高級言語の中でも、Java にはクラス ファイルがあり、Python にはインポート メカニズムがあり、PHP には include と require があります。 JS が タグを介してコードを導入する方法は複雑に見えます。以前は、コードを人為的に制限するには、名前空間やその他の方法を使用する必要がありました。フロントエンドとバックエンドの Javascript を統合できるようになったのは、CommonJS 仕様の登場です。 Node は CommonJS の Modules 仕様を利用して、非常に使いやすいモジュール システムを実装します。

1. CommonJS モジュールの仕様

CommonJS のモジュール仕様は 3 つの部分に分かれています:

1). モジュール参照: require() メソッドを通じてモジュールの API を現在のコンテキストに導入し、var math = require('math'); などのモジュール識別子を渡します。 2).モジュール定義: 現在のモジュールのメソッドまたは変数を、exports オブジェクトを通じてエクスポートします。モジュール内にはモジュール オブジェクトもあり、エクスポートは実際にはモジュールの属性です。 Node では、ファイルはモジュールであり、モジュール内の「グローバル変数」は外部からは見えません。exports.add = function() {}; のように、エクスポートにマウントされた属性のみが公開されます。 = 3.1415926; 3). モジュール識別: 実際には、上記の「math」など、require() に渡されるパラメータであり、camel 命名法に準拠した文字列、または「.」「..」で始まる相対パスである必要があります。または絶対パス。ファイル名の接尾辞「.js」は不要です

2. ノードモジュール実装プロセス

Node では、モジュールは 2 つのカテゴリに分類されます。1 つは Node 自体が提供するコア モジュール、もう 1 つはユーザーが作成したファイル モジュールです。コア モジュールの一部は、Node のソース コードのコンパイル プロセス中にバイナリ ファイルにコンパイルされます。コア モジュールは、Node の起動時にメモリに直接ロードされるため、ロード速度が最も速くなります。ファイル モジュールは実行時に動的にロードされ、パス分析、ファイルの場所、コンパイルと実行の 3 つの手順が必要です。なお、Nodeは二次導入コストを削減するためにインポートしたモジュールをキャッシュしており、同一モジュールの二次ロードは最優先のキャッシュからロードする戦略を採用しています。

2.1 パス分析

パス分析では主に上記のモジュール識別子が分析され、主に次のカテゴリに分類されます。 1)、http、fs、path などのコア モジュール。

2) . または .. で始まる相対パス ファイル モジュール 3) / で始まる絶対パスファイルモジュール 4). カスタム ファイル モジュール。ファイルまたはパッケージの形式である場合があります。ノードはモジュール パス配列 module.paths に従ってターゲット ファイルを 1 つずつ検索しようとします。通常、現在のディレクトリに沿ってルート ディレクトリまで段階的に node_modules という名前のディレクトリを検索します。そのため、これが最も時間のかかる方法です。それを見つけるために。

2.2 ファイルの配置 パス分析に基づいて、ファイルの場所では次の詳細に注意する必要があります:

1) ファイル拡張子の解析: CommonJS の仕様ではモジュール識別子に拡張子を記入しないことが認められているため、Node は .js、.json、.node の順に拡張子を記入して順番に試行します

2) ディレクトリ分析とパッケージ: 上記のファイル拡張子の分析後に対応するファイルが見つからなかったが、ディレクトリが取得された場合、ノードはそのディレクトリをパッケージとして扱います

2.3 コンパイルと実行 特定のファイルを見つけた後、Node は新しいモジュール オブジェクトを作成し、パスに従ってロードしてコンパイルします。拡張機能が異なると、読み込み方法も異なります:

1)、.js ファイル: fs モジュールを通じてファイルを同期的に読み取り、コンパイルして実行します

2).node ファイル: これは C/C で書かれ、dlopen() メソッド を通じてロードされる拡張ファイルです。 3).json ファイル: fs モジュールを通じてファイルを同期的に読み取り、JSON.parse() を使用して解析して結果を返します 4). その他の拡張子ファイル: .js ファイルとしてロードされます

各モジュール ファイルには、デフォルトで、require、exports、および module という 3 つの変数があることがわかっています。Node の API ドキュメントでも、各モジュールには、filename と dirname という 2 つの変数があることがわかります。 Node のモジュールは、宣言された「グローバル変数」が実際に他のモジュールを汚染しないことをどのように保証するのでしょうか?実際、Node は JS モジュールのコンパイル中にファイルの内容の先頭と末尾をラップします。以下は、先頭と末尾のパッケージ化を含む JS ファイルの例です:

コードをコピー コードは次のとおりです: (function(exports, require, module, __filename, __dirname) { /* 真ん中は実際の JS ファイルの内容です */ var math = require('math'); exports.area = function(radius) { 戻り Math.PI * 半径 * 半径; }; /* JS ファイルの実際の内容は終わりです */ }); このようにして、各モジュール ファイルはスコープで分離され、require、exports、module などの変数もモジュールのコンテキストに挿入されます。これは、CommonJS モジュール仕様の Node の実装です。 C/C モジュールとノード コア モジュールのコンパイル プロセスは比較的複雑なので、詳細は説明しません。

3. モジュール呼び出しスタック

以下の図に示すように、Node 内のさまざまなモジュールの呼び出し関係を明確にする必要があります。

C/C 組み込みモジュールは最下位のモジュールであり、主に Javascript コア モジュールとサードパーティの Javascript ファイル モジュールを呼び出すための API を提供します。実際には、このようなモジュールが公開されることはほとんどありません。 Javascript コア モジュールには 2 つの主な役割があります。1 つはファイル モジュール呼び出し用の C/C 組み込みモジュールのカプセル化層およびブリッジング層として機能すること、もう 1 つは純粋に機能するモジュールであり、最下層。ファイル モジュールは通常、通常の Javascript モジュールや C/C 拡張モジュールなどのサードパーティによって作成されます。

4. パッケージと NPM

4.1 パッケージ構造

パッケージは基本的にアーカイブ ファイル (通常は .zip または .tar.gz) であり、インストール後に解凍してディレクトリに復元できます。 CommonJS パッケージ仕様は、パッケージ構造とパッケージ説明ファイルの 2 つの部分で構成されます。 CommonJS 仕様に完全に準拠したパッケージ構造には、次のファイルが含まれている必要があります:

1).package.json: パッケージ説明ファイル 2).bin: 実行可能なバイナリファイルが保存されるディレクトリ 3).lib: Javascript コードを格納するディレクトリ 4).doc: ドキュメントを保存するディレクトリ 5).test: 単体テスト ケースを保存するディレクトリ

4.2 パッケージ記述ファイル

パッケージ説明ファイルは、パッケージのルート ディレクトリにある JSON ファイル、package.json であり、パッケージの重要な部分であり、パッケージの一般情報を記述するために使用されます。後で説明する NPM のすべての動作は、このファイルのフィールドと密接に関連しています。以下では、よく知られた Web フレームワーク Express プロジェクトの package.json ファイルを例として使用して、いくつかの一般的なフィールドの意味を説明します。

1).name: パッケージ名 2).description: パッケージの紹介 3).version: バージョン番号。「セマンティック バージョン管理」に準拠する必要があります。http://semver.org/ を参照してください。 4).dependency: 現在のパッケージを使用するために必要なパッケージのリスト。この属性は非常に重要です。NPM はこの属性を通じて依存パッケージを自動的にロードします 5).repositories: ソースコードがホストされている場所のリスト

他のフィールドの使用法については、NPM package.json の説明を参照してください

4.3 NPM 共通機能

NPM (ノード パッケージ マネージャー)、通常はノード パッケージ マネージャーと呼ばれます。その主な機能は、インストール、アンインストール、更新、表示、検索、リリースなどのノード パッケージを管理することです。

4.3.1 NPM パッケージのインストール

Node パッケージのインストールには、ローカル インストールとグローバル インストールの 2 種類があります。 2 つの違いは次のとおりです:

1). ローカルインストール npm install : パッケージは現在のディレクトリにダウンロードされ、現在のディレクトリでのみ使用できます。 2). グローバル インストール npm install -g : パッケージは特定のシステム ディレクトリにダウンロードされ、インストールされたパッケージはすべてのディレクトリで使用できます。

4.3.2 NPM パッケージ管理

以下では、一般的に使用されるパッケージ管理コマンドをリストする例として grunt-cli (grunt コマンド ライン ツール) を取り上げます:

1).npm install: package.json ファイルの依存関係フィールドと devDependency フィールドで宣言されたすべてのパッケージをインストールします 2).npm install grunt-cli@0.1.9: 特定のバージョンの grunt-cli をインストールします。 3).npm install grunt-contrib-copy --save: grunt-contrib-copy をインストールし、依存関係を package.json ファイルに保存します 4).npm uninstall grunt-cli: パッケージ をアンインストールします 5).npm リスト: どのパッケージがインストールされているかを確認します 6).npm public ：パッケージを公開