まあ、あなたはこの古典的な写真なしではできません：
仕組み
一般に、ロケット科学はありません-package.jsonとpackage-lock.jsonを取得し、そこにあるすべての依存関係を調べて、同一のモジュールまたはforkモジュールを収集します。 もちろん、フォークはあなたの手で書かなければならないので、今ではlodashとundescoreだけがリストされています。 しかし、あなたはいつでもこのリストを手伝って拡大することができます。
使い方
モジュールはnpmで公開されており、 npxを使用して実行するのが最も簡単です。ただし、ローカルまたはグローバルにインストールする必要はありません。 次に、npxを実行するオプションを検討します。 たとえば、古いプロジェクトの1つを取り上げます。これは、本質的にノード上のモノリスです（これはマイクロサービスブームの前であり、その後、それは怠andで非実用的でした）。
1.
npx wtfwith moduleName
（たとえば、
npm wtfwith lodash
）-特定のモジュールの出現回数を確認し、3つ以上ある場合は結果を表示します。 たとえば、結果は次のようになります。
一例
npx wtfwith lodash
npx: installed 3 in 2.047s
Searching for lodash
Checking path /web/xxx/package-lock.json
Huston, we have a problem:
30 versions of lodash:
- 2.4.2 from root, cheerio@0.18.0
- 3.10.1 from xmlbuilder@2.6.4
- 4.0.0 from twilio@3.15.0
- 4.17.4 from graphlib@2.1.1, sway@1.0.0
- 4.17.5 from aws-sdk@2.211.0, xmlbuilder@4.2.1, request-promise-core@1.1.1, requestretry@1.13.0
- lodash.assign:4.2.0 from ioredis@3.2.2
- lodash.bind:4.2.1 from ioredis@3.2.2
- lodash.clone:4.5.0 from ioredis@3.2.2
- lodash.clonedeep:4.5.0 from ioredis@3.2.2
- lodash.defaults:4.2.0 from ioredis@3.2.2
- lodash.difference:4.5.0 from ioredis@3.2.2
- lodash.flatten:4.4.0 from ioredis@3.2.2
- lodash.foreach:4.5.0 from ioredis@3.2.2
- lodash.get:4.4.2 from z-schema@3.18.4
- lodash.includes:4.3.0 from jsonwebtoken@8.2.1
- lodash.isboolean:3.0.3 from jsonwebtoken@8.2.1
- lodash.isempty:4.4.0 from ioredis@3.2.2
- lodash.isequal:4.5.0 from z-schema@3.18.4
- lodash.isinteger:4.0.4 from jsonwebtoken@8.2.1
- lodash.isnumber:3.0.3 from jsonwebtoken@8.2.1
- lodash.isplainobject:4.0.6 from jsonwebtoken@8.2.1
- lodash.isstring:4.0.1 from jsonwebtoken@8.2.1
- lodash.keys:4.2.0 from ioredis@3.2.2
- lodash.noop:3.0.1 from ioredis@3.2.2
- lodash.once:4.1.1 from jsonwebtoken@8.2.1
- lodash.partial:4.2.1 from ioredis@3.2.2
- lodash.pick:4.4.0 from ioredis@3.2.2
- lodash.sample:4.2.1 from ioredis@3.2.2
- lodash.shuffle:4.2.0 from ioredis@3.2.2
- lodash.values:4.3.0 from ioredis@3.2.2
Advice: Sometimes it is good to make a fresh start: rm ./ -rf && git commit -am 'nevermore' && git push origin master
2.
npx wtfwith everything
（単純に引数を省略して「npx wtfwith」と書くことができますが、これは意気消沈しています）-通常、3つ以上のバージョンであるすべての依存関係をチェックします。 たぶん、例えば、この結果：
例
npx wtfwith lodash
npx: installed 3 in 1.813s
Searching all strange things...
Checking path /web/xxx/package-lock.json
Huston, we have a problem:
30 versions of lodash:
// ,
4 versions of punycode:
- 1.2.4 from dkim-signer@0.1.2
- 1.3.2 from url@0.10.3
- 1.4.1 from tough-cookie@2.3.3
- 2.1.0 from uri-js@3.0.2
4 versions of xmlbuilder:
- 0.4.2 from nodemailer@0.7.1, aws-sdk@2.0.5
- 2.6.4 from root, xml2js@0.4.8
- 4.2.1 from aws-sdk@2.211.0, xml2js@0.4.17
- 9.0.1 from twilio@3.15.0
3 versions of xmldom:
- 0.1.19 from xml-crypto@0.10.1
- 0.1.27 from pdf2json@0.6.2
- 0.1.7 from ws.js@2.0.22
3 versions of mime:
- 1.2.11 from mailcomposer@0.2.12
- 1.4.1 from superagent@3.8.0
- 2.3.1 from root
3 versions of sax:
- 0.4.2 from xml2js@0.2.6
- 0.6.1 from xml2js@0.4.8
- 1.2.1 from aws-sdk@2.211.0, xml2js@0.4.17
3 versions of uuid:
- 1.4.2 from root
- 3.1.0 from aws-sdk@2.211.0
- 3.2.1 from request@2.83.0, request@2.85.0, requestretry@1.13.0, twilio@3.15.0
3 versions of xml2js:
- 0.2.6 from nodemailer@0.7.1, aws-sdk@2.0.5
- 0.4.17 from aws-sdk@2.211.0
- 0.4.8 from root
3 versions of moment:
- 2.19.3 from twilio@3.15.0
- 2.20.1 from moment-timezone@0.5.14
- 2.22.1 from root, joi@4.9.0, moment-range@1.0.9, moment-timezone@0.4.0, moment-timezone@0.5.15
3 versions of readable-stream:
- 1.0.34 from match-stream@0.0.2, pullstream@0.4.1, slice-stream@1.0.0, unzip@0.1.11
- 1.1.14 from dicer@0.2.5, ftp@0.3.10, htmlparser2@3.8.3, nodemailer@0.7.1
- 2.3.3 from mysql@2.14.1, superagent@3.8.0
Advice: What about lunch?
3.たとえば、依存関係の
--dev
バンドルをビルドする場合に
--dev
オプションを指定することもできます。 そのためには、バンドルの分析にフロントエンドツールを使用することをお勧めします。 使用例は示しません。コマンドは
npx wtfwith everything --dev
ように見えますが、そこに何があるのか想像できます。
実際の例
もちろん、私が行ったいくつかの人気のあるパッケージを分析することは興味深いでしょう。
1. エクスプレス -驚くべきことに、興味深いものは見つかりませんでした。
2. gulp-あらゆる種類の小さなものが見つかりました。
見て？
4 versions of kind-of:
- 3.2.2 from is-accessor-descriptor@0.1.6, is-data-descriptor@0.1.4, is-number@3.0.0, make-iterator@1.0.0, object-copy@0.1.0, snapdragon-util@3.0.1, to-object-path@0.3.0
- 4.0.0 from has-values@1.0.0
- 5.1.0 from array-sort@1.0.0, class-utils@0.3.6, is-descriptor@0.1.6, default-compare@1.0.0, expand-brackets@2.1.4, snapdragon@0.8.2, static-extend@0.1.2
- 6.0.2 from braces@2.3.1, is-accessor-descriptor@1.0.0, is-data-descriptor@1.0.0, is-descriptor@1.0.2, micromatch@3.1.10, nanomatch@1.2.9, use@3.1.0
3 versions of define-property:
- 0.2.5 from class-utils@0.3.6, expand-brackets@2.1.4, object-copy@0.1.0, snapdragon@0.8.2, static-extend@0.1.2
- 1.0.0 from base@0.11.2, braces@2.3.1, extglob@2.0.4, snapdragon-node@2.1.1
- 2.0.2 from micromatch@3.1.10, nanomatch@1.2.9, to-regex@3.0.2
3. npmはかなり面白い結果です。
見て！
14 versions of lodash:
- 3.10.1 from cli-table2@0.2.0
- lodash._baseindexof:3.1.0 from root
- lodash._baseuniq:4.6.0 from root
- lodash._bindcallback:3.0.1 from root
- lodash._cacheindexof:3.0.2 from root
- lodash._createcache:3.1.2 from root
- lodash._createset:4.0.3 from lodash._baseuniq@4.6.0
- lodash._getnative:3.9.1 from root, lodash._createcache@3.1.2
- lodash._root:3.0.1 from lodash._baseuniq@4.6.0
- lodash.clonedeep:4.5.0 from root
- lodash.restparam:3.6.1 from root
- lodash.union:4.6.0 from root
- lodash.uniq:4.5.0 from root
- lodash.without:4.4.0 from root
3 versions of mississippi:
- 1.3.1 from make-fetch-happen@2.6.0
- 2.0.0 from cacache@10.0.4
- 3.0.0 from root, pacote@7.6.1
3 versions of pump:
- 1.0.3 from mississippi@1.3.1
- 2.0.1 from mississippi@2.0.0, pumpify@1.4.0
- 3.0.0 from mississippi@3.0.0
少なくとも、npmがlodashの使用を最小限に抑えようとしているのは面白いことですが、依存関係の1つに完全に取り付かれています...
藤堂
プロジェクトはひざまずいて書かれたため、そこで実装されていないものがいくつかあります。
1. shrinkwrapファイルでの作業はありませんが、これはあまり必要ではありません。検証のためにパッケージロックを生成するだけです。
2.ノード6+のみがサポートされます。 nvmがあるため、あまり重要ではありません。
3. yarnのラーンファイルはサポートされていません。 ここでも重要ではありません。
4.確かに多くのバグと不正確さがあります。
一般的に、ツールがあなたに関連している場合、プルリクエストは大歓迎です。
結論
結果はあまり見栄えが良くありませんが、正直なところ、私はもっと地獄を期待していました。 どうやら、多くの人が依然として更新と依存関係の保護を分析するためのツールを使用しています。
物議を醸す勧告から：
1.意図的にバックエンドモジュールを使用して、lodashのような依存関係を細かく分割することはお勧めしません。とにかく、誰かが確実にライブラリのフルバージョンを削除します。 もちろん、セマンティックバージョニングを忘れないでください-もちろん、正確なバージョン制限がないと、ある時点ですべてが壊れる可能性がありますが、これは厳密な制限ではなく、パッケージロックと開発者間の相互作用の依存関係を修正することで解決する必要があります。 つまり、何らかの依存関係の重大な変更を見つけた場合、パッケージの作成者に連絡して、それが間違っていると言うといいでしょう-これにより、他の人の労力とテラバイトのディスクスペースが節約されます。
ここで私が尊敬している著者はioredis の正反対です。
2.依存関係を定期的に実行して、依存関係の疑わしい部分を確認し、問題のサブスクライブを解除するか、問題のあるモジュールにプルリクエストを行うことは価値があります。
依存関係の更新の問題があなたに近い場合、最終的にいくつかの便利なツールをアドバイスできます。
1. npm-check-updates-パッケージバージョンの更新をすばやく確認し、すぐにインストールします。 注意してください！
2. snyk-パッケージのセキュリティをチェックします。私はすでに少し前にそれについて書きました 。
3. ノードセキュリティプロジェクトは、依存関係セキュリティをチェックするための別のツールです。これは、最近npmに買収されたため、エコシステムのネイティブと見なすことができます。
4.フロントで作業している場合は、おそらくwebpack-bundle-analyzerのようなものを使用しています。これにより、結果として得られたものが正確にわかります。 しかし、私は前線で働いていないので、明確な勧告をすることはできません。
5.何かが古くなったり、安全でなくなったりした場合に明確に表示して通知する、あらゆる種類のバッジとCI統合を使用すると便利です。 バッジの例は紹介しませんが、バッジはたくさんあります。また、 shields.ioの一部を見ることができます。 多くの統合もあり、オープンソースプロジェクトがある場合、travis-ciはほとんどすべての種類のテストを実行できます。
このような投稿は定期的に表示されますが、時間が経ちます。現在、プロジェクトで使用している便利なチェックとツールを教えてください。