NBAからパッケージを削除する状況が発生した後、膨大な数のbabel 、 jscsなどのユーザー（ 「インターネットの破壊に関する議論」を参照）の多くのユーザーに影響を与えた後、多くのオープンソース開発者が話し始めましたNPMとJSエコシステム全体の未来。
意見は分かれています：
- 「NPMと左パッド：プログラミング方法を忘れましたか？」という単純すぎるパッケージに対する批判がありました。
- 他の人はNPM独占について考えました： 「あるプログラマーは11行のコードを削除することでインターネットをほぼ破壊しました」 。
- さらに他の人たちは、JSエコシステムがいかに壊れやすいかについて話している： 「左パッドは壊れやすいJavaScriptエコシステムを示していますか？」
さて、githubで膨大な数のチケットを落とした大規模なオープンソースパッケージのチームは、今後この状況を防ぐ方法について真剣に考えました。 CIでよく使用されるプロジェクトは、依存関係の欠落に関する問題に最初に気付いたのはCIユーザーだったため、特に影響を受けました。 これらのプロジェクトの1つはESLintで 、 1日あたり約7万のインストールがあり、そのほとんどはCIアセンブリにあります。
ESLint開発チームの決定は非常に急進的でしたが、非常に効果的でした。 彼らは、すべての依存関係を含むESLintパッケージを公開することにしました。 つまり、ESLintアーカイブをダウンロードすると、npmユーティリティは必要なバージョンのESLintの作業中のnode_modules全体もダウンロードします。
この変更の詳細： 「ESLint v2.5.0リリース」
このニュースを知って最初に思いついたのは、パフォーマンスに関するものでした。 ESLintのインストールはどうなりますか？ 速くなりますか、遅くなりますか。 小さな実験により、組み込みの依存関係を持つパッケージのインストールには時間がかかることが示されました。 ESLintの場合-2秒間（〜25％）：
npm install eslint@2.4.0 6.22s user 2.68s system 108% cpu 8.207 total npm install eslint@2.5.0 7.70s user 4.16s system 109% cpu 10.864 total
完全な結論
$ rm -Rf node_modules && time npm install eslint@2.4.0 && rm -Rf node_modules && time npm install eslint@2.5.0 eslint@2.4.0 node_modules/eslint ├── path-is-absolute@1.0.0 ├── ignore@2.2.19 ├── pluralize@1.2.1 ├── path-is-inside@1.0.1 ├── globals@8.18.0 ├── estraverse@4.2.0 ├── strip-json-comments@1.0.4 ├── esutils@2.0.2 ├── progress@1.1.8 ├── text-table@0.2.0 ├── user-home@2.0.0 (os-homedir@1.0.1) ├── is-resolvable@1.0.0 (tryit@1.0.2) ├── shelljs@0.5.3 ├── json-stable-stringify@1.0.1 (jsonify@0.0.0) ├── resolve@1.1.7 ├── debug@2.2.0 (ms@0.7.1) ├── doctrine@1.2.0 (esutils@1.1.6, isarray@1.0.0) ├── optionator@0.8.1 (fast-levenshtein@1.1.3, type-check@0.3.2, levn@0.3.0, wordwrap@1.0.0, deep-is@0.1.3, prelude-ls@1.1.2) ├── mkdirp@0.5.1 (minimist@0.0.8) ├── require-uncached@1.0.2 (resolve-from@1.0.1, caller-path@0.1.0) ├── chalk@1.1.1 (escape-string-regexp@1.0.5, supports-color@2.0.0, has-ansi@2.0.0, strip-ansi@3.0.1, ansi-styles@2.2.0) ├── concat-stream@1.5.1 (inherits@2.0.1, typedarray@0.0.6, readable-stream@2.0.6) ├── espree@3.1.3 (acorn@3.0.4, acorn-jsx@2.0.1) ├── is-my-json-valid@2.13.1 (jsonpointer@2.0.0, generate-function@2.0.0, xtend@4.0.1, generate-object-property@1.2.0) ├── inquirer@0.12.0 (ansi-regex@2.0.0, strip-ansi@3.0.1, ansi-escapes@1.3.0, figures@1.5.0, rx-lite@3.1.2, through@2.3.8, cli-width@2.1.0, run-async@0.1.0, cli-cursor@1.0.2, string-width@1.0.1, readline2@1.0.1) ├── table@3.7.8 (slice-ansi@0.0.4, tv4@1.2.7, xregexp@3.1.0, strip-ansi@3.0.1, string-width@1.0.1, bluebird@3.3.4) ├── js-yaml@3.5.5 (esprima@2.7.2, argparse@1.0.7) ├── glob@6.0.4 (inherits@2.0.1, inflight@1.0.4, once@1.3.3, minimatch@3.0.0) ├── file-entry-cache@1.2.4 (object-assign@4.0.1, flat-cache@1.0.10) ├── es6-map@0.1.3 (d@0.1.1, es6-symbol@3.0.2, event-emitter@0.3.4, es6-iterator@2.0.0, es6-set@0.1.4, es5-ext@0.10.11) ├── escope@3.6.0 (esrecurse@4.1.0, es6-weak-map@2.0.1) └── lodash@4.6.1 npm install eslint@2.4.0 6.22s user 2.68s system 108% cpu 8.207 total eslint@2.5.0 node_modules/eslint npm install eslint@2.5.0 7.70s user 4.16s system 109% cpu 10.864 total
アーカイブに依存関係を含めるには、package.jsonのbundledDependencies設定を使用します（詳細については、 「package.json bundledDependencies」を参照してください）。 この設定は簡単です。公開されたアーカイブに含まれるパッケージ名の配列を受け入れます。
依存関係を公開するプロセスを自動化するために、ESLintは小さなパッケージbundle-dependenciesを使用します。これは、依存関係からbundledDependenciesを形成し、package.jsonに書き込みます。
実際、NPMレジストリに公開されていない依存関係を含めるためにbundledDependenciesオプションが考案されたため、このアプローチはNPMの考え方にやや反しています。
JSCSで私たちは何をするかをまだ決めていません。 オープンソースプロジェクトの他の開発チームがNPMの状況にどのように反応するか（そして彼らが反応するかどうか）を見るのは興味深いでしょう。 このアプローチが根を下ろすか、他の選択肢が見つかるかを見てみましょう。
UPD：発生した問題のため、ESLintはbundledDependenciesに関連する変更をロールバックしました。 詳細： 「npm shrinkwrap failed> = 2.5.0」