node_moduleのチェックインはコミュニティの標準でしたが、シュリンクラップを使用するオプションもあります。後者の方が私には理にかなっていますが、誰かが「強制公開」してバグを導入した可能性は常にあります。追加の欠点はありますか?
2 に答える
このテーマに関する私のお気に入りの投稿/哲学は、2011年までさかのぼります(node.jsの土地で長い間):
https://web.archive.org/web/20150116024411/http://www.futurealoof.com/posts/nodemodules-in-git.html
直接引用するには:
デプロイするアプリケーションがある場合は、すべての依存関係をnode_modulesにチェックインします。npm do deployを使用する場合は、それらのモジュールに対してのみbundleDependenciesを定義してください。コンパイルする必要のある依存関係がある場合でも、コードをチェックインし、デプロイ時に$npmrebuildを実行する必要があります。
私がこれを言ったすべての人は、私がばかだと言って、数週間後に私が正しかったと言って、gitにnode_modulesをチェックインすることは展開と開発に祝福をもたらしました。客観的には良いのですが、ここに私が受けたと思われる質問/苦情のいくつかがあります。
これはまだ最善のアドバイスだと思います。
強制公開のシナリオはまれであり、npm shrinkwrap
おそらくほとんどの人にとってうまくいくでしょう。node_modules
ただし、実稼働環境にデプロイする場合は、ディレクトリ全体をチェックインするほど安心できるものはありません。
あるいは、本当にnode_modules
ディレクトリをチェックインしたくないが、強制的なプッシュが行われていないことをより確実にしたい場合は、次のアドバイスに従いますnpm help shrinkwrap
。
ビザンチンの作成者が使用しているパッケージをアプリケーションを壊すコードに置き換えるリスクを回避したい場合は、npmが常にすべてのパッケージをgitからフェッチするように、バージョン番号ではなくgitURL参照を使用するようにshrinkwrapファイルを変更できます。
もちろん、誰かが奇妙なことを実行しgit rebase
てgit commit hashを変更する可能性があります...しかし、今は夢中になっています。
npm FAQはこれに直接答えます:
- ウェブサイトやアプリなど、デプロイするものについては、node_modulesをgitにチェックインします。
- 再利用を目的としたライブラリとモジュールのgitにnode_modulesをチェックインしないでください。
- npmを使用して、開発環境の依存関係を管理しますが、デプロイメントスクリプトでは管理しません。
npmFAQから引用