Node.JSでのバックエンドの下痢-ビルドの重量を減らす

確かに、ノードモジュール内にゴミがどれだけあるかに気づいたことでしょう。 これらは、テスト、ベンチマーク、readmeファイル、ライセンス、タイムスクリプト、および多かれ少なかれ安全に削除できる別の異常な量のゴミです。 この投稿で実際に行うこと。

ノードモジュールの重みに関する最後のいくつかの出版物については既に言及しましたので、現在の状況を一般的に反映する別の出版物を紹介します。 投稿のサウンドトラックは、Little Big、「Life in da trash」です。













開始する



そのため、誤ってノードモジュールの内部に移動することで悲しくなり、プロジェクトを実行した手で実験用のスクリプトをいくつか書くことから始めました。 彼らは次のように見えました:







find ./ -iname "tests" -exec rm -rf {} \; find ./node_modules -iname "test" -exec rm -rf {} \; find ./node_modules -iname "*.gif" -exec rm -rf {} \; find ./node_modules -iname "*.jpg" -exec rm -rf {} \; find ./node_modules -iname "*.jpeg" -exec rm -rf {} \; find ./node_modules -iname "*.png" -exec rm -rf {} \; find ./ -iname "*.md" -exec rm -rf {} \; find ./ -iname "*.log" -exec rm -rf {} \; find ./ -iname "LICENSE*" -exec rm -rf {} \; find ./ -iname "README*" -exec rm -rf {} \; find ./ -iname "LICENCE*" -exec rm -rf {} \; find ./ -iname "AUTHORS*" -exec rm -rf {} \; find ./ -iname "NOTICE*" -exec rm -rf {} \; find ./ -iname "changelog*" -exec rm -rf {} \; find ./ -iname ".travis.yml" -exec rm -rf {} \; find ./ -iname ".coveralls.yml" -exec rm -rf {} \; find ./ -iname ".npmignore" -exec rm -rf {} \; find ./ -iname ".gitignore" -exec rm -rf {} \; find ./ -iname ".jshintrc" -exec rm -rf {} \; find ./ -iname ".eslintrc" -exec rm -rf {} \; find ./ -iname ".jscs.json" -exec rm -rf {} \; find ./ -iname ".editorconfig" -exec rm -rf {} \; find ./ -iname ".vs" -exec rm -rf {} \; find ./ -iname ".babelrc" -exec rm -rf {} \;
      
      





一般に、これはすでに悪くはなく、いくらか節約できましたが、もっとエレガントで一般的なソリューションが必要でした。 そしてすぐに、私が望んでいたことを正確に行うモジュール-ModCleanを見つけました。







Modclean



モジュールには多数の設定があり、npmパッケージとして接続するプラグインの形式の「追加ファイル」のリストもあります。 デフォルトでは、 そのようなリストがあります。







削除セキュリティ用の3つのレベルのファイルがあります-リストを見て、何が問題を引き起こす可能性があるかを確認することを強くお勧めします。 たとえば、リストに「semver」が含まれている理由がわかりませんでした...







唯一のマイナス-何らかの理由で、モジュールの作成者は、自分のプロジェクトに組み込む前にすべてのゴミを削除したいとは思わなかった-たとえば、本番環境でテストファイルは絶対に必要ない...

確かに、プロジェクトディレクトリをモジュールディレクトリとして指定することで、これを簡単に回避できることがわかりました。







 modclean --modules-dir .
      
      





結果



プロジェクトによって結果が大きく異なる可能性があることは明らかですが、10%から20%の節約になりました。 高度なケースでは、さらに多くの可能性があります。 これは最大の数とは思えないかもしれませんが、これは必要なストレージスペースを20%削減し、文字通り何もないプロジェクトの20%高速なロールアウトです。

好奇心の強い人のために、モジュールのサイトには削除のベンチマークもありますが、自分で試してみるのが良いでしょう。







下痢



この肯定的なメモで、私は自分の問題を解決したと言いたいと思います。この美しいモジュールを使用することを皆に勧めます。 しかし、タイトルには「modclean」ではなく「下痢」という言葉がありましたか? これは、もう1つのニュアンスがあることを意味します。 ニュアンスは文字通りの意味でかなり厚く、モジュールには123個の推移的な依存関係があり、4MBの重さがあることが判明しました。 これは一般に、ノードモジュールの標準とは多かれ少なかれ既に考えられていますが、精神的な苦痛をもたらす以外にありません。







同時に、非常に人気のあるupdate-notifierモジュールは1.2メガバイトを占有し、更新が利用可能な場合に備えてこのフレームを描画するだけです。



このために1メガバイト、カール! Node.JS開発者として、私は恥ずかしく思っています。







そして、残りの場所のほとんどはcluiモジュールで占められています 。これには、ターミナルを操作するためのあらゆる種類の装飾が含まれています。そのうちのいくつかの機能しか使用されていません。







一般的に、私はこれに耐えることができず、組み立てを行いました-ブラックジャックやその他すべてなしで。 そこから更新通知を完全に切り取り、webpackを使用して、多数の依存関係を持つシックモジュールから必要な機能を縮小したバンドルに収集しました。 一般的に、モジュールの重量を少しでも減らすことができました-しかし、私は700キロバイトの重量に達し、今のところ落ち着きました。 また、依存関係ではなく、プロジェクトのルートをより明確にクリーンアップできる--rootオプションも追加しました。







これらすべての理由のためにIssueをmodcleanに投げ込み、そこでプルリクエストを行い、すべてが承認された場合、メインモジュールを支持してこのフォークを修正します-しかし、今のところmodcleanは放棄されているという感覚があります-良いアイデアがあればそれらを私に投げてください。







いつものように、npmから私のバージョンをインストールできます。







警告



必要なものがすべてリポジトリに保存されていることを再確認してください-下痢は、不要なファイル、必要なファイル、歯を削除し、子猫を殺すことができます。 私はこれに対するすべての責任を取ります。







CIでの統合



このような下痢を使用するのが最善です:







  1. まず、ノードモジュールからすべてのゴミを削除します。
  2. 次に、ユニットテストを実行して、それらに余分なものがないことを確認します。
  3. 次に、テスト自体を含むメインプロジェクトからガベージを削除します。
  4. npm prune --production;
  5. アーティファクトを収集します。


藤堂



このモジュールは個人用に急いで作成されたため、将来的には以下を追加したいと思います。









結論





まあ、それだけです。







興味があれば、このトピックに関する他の記事も好きかもしれません。









また、バックエンドでNode.JSを永続的に使用するさまざまなケースについても説明できます。興味がある場合は調査に参加してください。








All Articles