ノードjsのモジュールローダーとローカルモジュールのサポート、およびオンデマンドのモジュールロード

私はフロントエンド開発者であり、最近、webpackを使用してプロジェクトを構築するか、さまざまなgulpタスクを設定するかに関係なく、ノードをより頻繁に使用する必要があります。 ノードの使用経験はあまりありませんが、時間の経過とともに、モジュールを操作するときに改善したい3つのことを蓄積しました。





3つすべての問題を個別に解決するために、さまざまなモジュールとソリューションが既にありますが、まず、それらのすべてに欠点があるように思われます。次に、3つの問題をすべて解決するソリューションはありません。



たとえば、モジュールをオンデマンドでロードする(別名、遅延ロードまたはロードオンデマンド)には、gulp-load-pluginsモジュールがあります。 1番目と2番目の問題は解決しますが、3番目の問題は解決せず、もう1つの欠点があります。モジュールを接続するには、これらのモジュールが必要な各ファイルでgulp-load-pluginsモジュールを初期化する必要があります もちろん、別のファイルで初期化してファイルから値をエクスポートすることもできますが、この場合、相対パスまたは絶対パスを使用してこのファイルを接続する必要があります。



3年目の問題を解決するために、約1年前、npmはいわゆるローカルモジュールのサポートを追加しました。 一番下の行は

依存関係のpackage.jsonでは、モジュール名をキーとして指定する必要があり、値では、接頭辞「file:」を持つローカルモジュールのフォルダーへの相対パスを指定する必要があります。たとえば、package.jsonファイルの一部は次のとおりです。



"dependencies": { "lodash": "^2.0.0", "core": "file:deep/deep/deep/core", "my-other-module": "file:/my-other-module" }
      
      





この場合、ローカルモジュールのフォルダーは通常のモジュールのように設計する必要があります。つまり、package.jsonファイルとreadme.mdファイルを含める必要があります。 npm iを起動すると、通常のモジュールと同様に、ローカルモジュールがnode_modulesフォルダーにインストールされます。 私にとって、これは、各プロジェクトファイルを個別のフォルダーに入れたり、package.jsonファイルやreadme.mdファイルを追加したりするのは非常に不便です。



一言で言えば、私は説明した問題の良い解決策を見つけられませんでした。検索が不十分だったかもしれませんが、さまざまなフォーラムを歩いてさまざまな新鮮な記事を読んで、人々はまだこれらすべての問題の良い解決策を探しているという結論に達しました。



最後に、私はあなたに伝えたい私の決定、おそらく私の自転車を書くことにしました。 判断するのはどれほど良いか悪いか。 それでは、sp-loadを紹介しましょう。 すぐに予約します。接頭辞sp-には神聖な意味はありません。これらは私の姓と名前の最初の文字であり、私を美化するために追加されたのではなく、名前「load」、「loader」、 。



プロジェクトでnpm i sp-load -Sを実行しました。 package.jsonファイルの次のコンテンツがあるとします。



 { "name": "your-project", "version": "1.0.0", "main": "index.js", "dependencies": { "lodash": "^3.10.1", "sp-load": "^1.0.0" }, "devDependencies": { "gulp": "^3.9.0", "webpack": "^1.12.9" }, "_localDependencies": { "core": "./core/core", "some-module": "./deep/deep/deep/deep/deep/deep/deep/some-module" } }
      
      





また、次のファイル構造があります。



 your-project/ node_modules sp-load/ ... gulp/ ... lodash/ ... webpack/ ... package.json core/ core.js deep/ deep/ deep/ deep/ deep/ deep/ deep/ some-module.js gulpfile.js index.js
      
      





最も単純な形式でsp-loadを使用するには、何をする必要がありますか? ただ一つ、var $ = require( 'sp-load'); たとえば、ファイル内のgulpfile.jsの内容は次のとおりです。



 'use strict'; var $ = require('sp-load'), webpackConfig = {}; $.gulp.task("webpack", function (callback) { $.webpack(webpackConfig, function (err, stats) { callback(); }); });
      
      





some-module.jsのコンテンツ:



 'use strict'; function someModuleFuction() { console.log('I\'m some module function call!'); } module.exports = someModuleFuction;
      
      





core.jsのコンテンツ:



 'use strict'; function coreModuleFuction() { console.log('I\'m core module function call!'); } module.exports = coreModuleFuction;
      
      





index.jsの内容:



 'use strict'; var $ = require('sp-load'); $.someModule(); $.core();
      
      





ご覧のとおり、sp-loadモジュールを接続するだけです。 これは、オンデマンドでロードされるモジュールのリストを含むオブジェクトを返します。つまり、モジュールは、$ .core()などのモジュール名で最初にアクセスされたときにノードによってロードされます。



また、おそらくpackage.jsonの非標準プロパティ「_localDependencies」に気づいたでしょう。 このプロパティでは、プロジェクトのローカルモジュールのリストを定義できます。 オブジェクトのキーはモジュールの名前、値はモジュールファイルへの相対パス(package.jsonファイルに相対的なパス)です。



モジュールをオブジェクトプロパティとしてではなく変数として参照する場合は、次のように実行できます(この例ではes6の構造化を使用しています。nodejsでes6を有効にする方法については、nodejsのドキュメントを参照してください)。



 'use strict'; var {someModule, core} = require('sp-load'); someModule(); core();
      
      





またはes5を使用:



 'use strict'; var $ = require('sp-load'), someModule = $.someModule, core = $.core; someModule(); core();
      
      





これらの両方の例では、一部のモジュールとコアモジュールが割り当て時にロードされますが、それらを最初に使用するときに(つまりオンデマンドで)ロードする場合は、モジュールを$オブジェクトのプロパティとして参照します。



これは、package.jsonで「_localDependencies」プロパティを使用することを除いて、sp-loadの最も簡単な使用であり、設定はありません。 次に、sp-loadがサポートする設定を示します。 sp-loadを構成するには、package_jsonに「_sp-load」プロパティを追加する必要があります。 以下にpackage.jsonファイルの例を示します。このファイルには、考えられるすべての設定と、それぞれの目的に関するコメントがリストされています。



 { "name": "your-project", "version": "1.0.0", "main": "index.js", "dependencies": { "lodash": "^3.10.1", "sp-load": "^1.0.0" }, "devDependencies": { "gulp": "^3.9.0", "webpack": "^1.12.9" }, "_localDependencies": { "core": "./core/core", "some-module": "./deep/deep/deep/deep/deep/deep/deep/some-module" }, "_sp-load": { /*   true,      camel case. ,  $['some-module']  $.someModule.   - true. */ "camelizing": false, /*       . ,  $.lodash     $._ */ "renaming": { "lodash": "_", "gulp": "supergulp" }, /*       ,   .  -  ,  - ,     .     - gulp ,       gulp-, , gulp-concat,        $.concat  $.gulpConcat. */ "replacing": { "/^gulp-/": "" } } }
      
      





package.jsonファイルを詰まらせたくない場合は、sp-load設定とローカルモジュールのリストを_sp-load.jsonファイルに配置します。これはpackage.jsonと同じフォルダーにある必要があります。



 yourProject/ package.json _sp-load.json
      
      





_sp-load.jsonファイルの内容の例を次に示します。



 { "_localDependencies": { "core": "./core/core", "some-module": "./deep/deep/deep/deep/deep/deep/deep/some-module" }, "_sp-load": { "camelizing": false, "renaming": { "lodash": "_", "gulp": "supergulp" }, "replacing": { "/^gulp-/": "" } } }
      
      





そして、私がまだ言及していない最後のこと。 $ = require( 'sp-load');を実行すると、$オブジェクトのプロトタイプに「_spModulesList」プロパティが含まれます。 このプロパティにはオブジェクトが含まれます。キーはモジュールの名前で、値はモジュールファイルへの絶対パスです。 このオブジェクトの内容の例を次に示します。



 { "lodash": "lodash", "sp-load": "sp-load", "gulp": "gulp", "webpack": "webpack", "core": "D://your-project//core//core.js", "some-module": "D://your-project//deep//deep//deep//deep//deep//deep//deep//some-module.js" }
      
      





これは何に役立ちますか? たとえば、System.jsブートローダーを使用する場合。



おそらくこれがすべてです。 モジュールをnpmjs.comで公開する前にテストしましたが、実際のプロジェクトではまだ使用していませんので、エラーがあった場合は報告していただければ幸いです。



モジュール自体へのリンク: sp-load



PS: npmjs.comから公開されたモジュールを削除する方法を教えてもらえますか? どこでもそれを行う方法を見つけられず、npm unpublishはモジュールを削除しますが、その後のnpm publishでは、モジュールバージョンを増やす必要があります。 npmは、現在のバージョンが既に登録されていることを誓います。



All Articles