web-dev-qa-db-ja.com

Herokuでnode.jsアプリを作成するときにgitにnode_modulesをチェックインする必要がありますか？

ここで、Herokuのnode.jsの基本的な開始手順に従いました。

https://devcenter.heroku.com/categories/nodejs

これらの命令は、.gitignore node_modulesを作成するようにあなたに指示しません。したがって、node_modulesがgitにチェックインされるべきであることを意味します。 gitにnode_modulesを含めると、はじめのアプリケーションが正しく実行されました。

私がより高度な例に従ったとき：

https://devcenter.heroku.com/articles/realtime-polyglot-app-node-Ruby-mongodb-socketiohttps://github.com/mongolab/tractorpush-server （ソース）

それは私にnode_modulesを.gitignoreに追加するように指示しました。そのため、gitからnode_modulesを削除し、それを.gitignoreに追加してから、再デプロイしました。今回はデプロイが失敗しました。

-----> Heroku receiving Push
-----> Node.js app detected
-----> Resolving engine versions
       Using Node.js version: 0.8.2
       Using npm version: 1.0.106
-----> Fetching Node.js binaries
-----> Vendoring node into slug
-----> Installing dependencies with npm
       Error: npm doesn't work with node v0.8.2
       Required: [email protected] || 0.5 || 0.6
           at /tmp/node-npm-5iGk/bin/npm-cli.js:57:23
           at Object.<anonymous> (/tmp/node-npm-5iGk/bin/npm-cli.js:77:3)
           at Module._compile (module.js:449:26)
           at Object.Module._extensions..js (module.js:467:10)
           at Module.load (module.js:356:32)
           at Function.Module._load (module.js:312:12)
           at Module.require (module.js:362:17)
           at require (module.js:378:17)
           at Object.<anonymous> (/tmp/node-npm-5iGk/cli.js:2:1)
           at Module._compile (module.js:449:26)
       Error: npm doesn't work with node v0.8.2
       Required: [email protected] || 0.5 || 0.6
           at /tmp/node-npm-5iGk/bin/npm-cli.js:57:23
           at Object.<anonymous> (/tmp/node-npm-5iGk/bin/npm-cli.js:77:3)
           at Module._compile (module.js:449:26)
           at Object.Module._extensions..js (module.js:467:10)
           at Module.load (module.js:356:32)
           at Function.Module._load (module.js:312:12)
           at Module.require (module.js:362:17)
           at require (module.js:378:17)
           at Object.<anonymous> (/tmp/node-npm-5iGk/cli.js:2:1)
           at Module._compile (module.js:449:26)
       Dependencies installed
-----> Discovering process types
       Procfile declares types -> mongod, redis, web
-----> Compiled slug size is 5.0MB
-----> Launching... done, v9

「heroku ps」を実行するとクラッシュが確認されます。問題ないので、変更をロールバックし、gitリポジトリにnode_moduleを追加し、.gitignoreから削除しました。ただし、元に戻した後でも、デプロイ時に同じエラーメッセージが表示されますが、アプリケーションは再び正常に動作しています。 "heroku ps"を実行すると、アプリケーションが実行されていることがわかります。

だから私の質問はこれを行うための正しい方法は何ですか？ node_modulesを含めるかどうかロールバック時にエラーメッセージが表示されるのはなぜでしょうか。私の推測では、gitリポジトリはHeroku側で悪い状態にありますか？

gitnode.jsherokunpmgitignore
356
Jason Griffin

セカンドアップデート

FAQはもう使用できません。

shrinkwrap のドキュメントから：

例えばデプロイメントやビルドを再現することができるという100％の自信を持っているために、パッケージに含まれる特定のバイトをロックダウンしたい場合は、依存関係をソース管理にチェックインするか、検証できる他のメカニズムを追求するべきです。バージョンではなく内容.

シャノンとスティーブンは前にこれについて述べました、しかし私はそれが受け入れられた答えの一部であるべきだと思います。

更新

以下の推奨事項 に記載されているソースが更新されました 。彼らはもはやnode_modulesフォルダのコミットを推奨していません。

通常、いいえ。 npmがあなたのパッケージの依存関係を解決できるようにします。

Webサイトやアプリケーションなど、デプロイするパッケージの場合は、npm shrinkwrapを使用して完全な依存関係ツリーをロックする必要があります。

https://docs.npmjs.com/cli/shrinkwrap

元の投稿

参考のために、npm FAQがあなたの質問に明確に答えます。

Webサイトやアプリなど、デプロイするものについては、node_modulesをgitにチェックインしてください。再利用を意図したライブラリやモジュールのためにgitにnode_modulesをチェックインしないでください。開発環境の依存関係を管理するにはnpmを使用しますが、展開スクリプトの依存関係は管理しません。

そしてこれに対するいくつかの良い理論的根拠については、これに関する Mikeal Rogersの投稿を読んでください 。

出典： https://docs.npmjs.com/misc/faq#should-i-check-my-node-modules-folder-into-git

388
Kostia

node_modulesをgitにチェックインしないことに対する私の最大の懸念は、本番用アプリケーションがまだ使用されている10年後に、npmが使用されなくなる可能性があることです。またはnpmが破損する可能性があります。あるいは、あなたが頼っているライブラリを彼らのリポジトリから削除することをメンテナが決めるかもしれません。またはあなたが使用するバージョンは削除されるかもしれません。

これは、Mavenのようなレポマネージャで軽減できます。なぜなら、あなたはあなたが使うパッケージとのミラーを維持するためにあなた自身のローカルNexusかArtifactoryをいつでも使うことができるからです。私が理解している限りでは、そのようなシステムはnpmには存在しません。 BowerやJamjsのようなクライアントサイドのライブラリマネージャも同様です。

ファイルを自分のgitリポジトリにコミットした場合は、好きなときにファイルを更新できます。繰り返し可能なビルドを使用でき、サードパーティの操作によってアプリが壊れることはないという知識が得られます。

157
Jonathan

node_modulesにnot include.gitignoreを使用する必要があります（または Herokuにデプロイされたソース にincludenode_modulesを使用する必要があります） 。

node_modulesの場合：

  • existsその後、npm installはそれらのベンダーのライブラリを使用し、npm rebuildでバイナリ依存関係を再構築します。
  • 存在しないその後、npm installはすべての依存関係をフェッチする必要があり、それによってスラッグのコンパイル手順に時間がかかります。

これらの正確な手順については、Node.jsビルドパックのソースを参照してください

ただし、元のエラーはnpmとnodeのバージョン間の非互換性のようです。これらの状況を回避するために、 このガイド に従ってpackages.jsonのenginesセクションを常に明示的に設定することをお勧めします。

{
  "name": "myapp",
  "version": "0.0.1",
  "engines": {
    "node": "0.8.x",
    "npm":  "1.1.x"
  }
}

これにより、 dev/prodパリティ が保証され、将来そのような状況が発生する可能性が低くなります。

67
Ryan Daigle

私はこのコメントの後にこれを残すつもりでした： Herokuでnode.jsアプリを作成するときにgitにnode_modulesをチェックインするべきですか？

しかしstackoverflowはそれを奇妙にフォーマットしていました。もしあなたが同一のマシンを持っておらず、node_modulesをチェックインしているのなら、ネイティブエクステンションに対して.gitignoreを実行してください。私たちの.gitignoreはように見えます：

# Ignore native extensions in the node_modules folder (things changed by npm rebuild)
node_modules/**/*.node
node_modules/**/*.o
node_modules/**/*.a
node_modules/**/*.mk
node_modules/**/*.gypi
node_modules/**/*.target
node_modules/**/.deps/
node_modules/**/build/Makefile
node_modules/**/**/build/Makefile

まずすべてをチェックインしてこれをテストしてから、別の開発者に次のことをさせます。

rm -rf node_modules
git checkout -- node_modules
npm rebuild
git status

ファイルが変更されていないことを確認してください。

22
ibash

私はnpm installを本番環境で実行しないでください。 npmの機能停止、新しい依存関係のダウンロード（shrinkwrapがこれを解決したようだ）がそのうちの2つです。

一方、node_modulesはgitにコミットされるべきではありません。大きなサイズを除けば、それらを含むコミットは気を散らすものになる可能性があります。

最善の解決策は次のとおりです。npm installは、実稼働環境に似たCI環境で実行する必要があります。すべてのテストが実行され、すべての依存関係を含むzip形式のリリースファイルが作成されます。

10
user2468170

Node_modulesフォルダのコミットとシュリンクラップの両方を使用しています。両方の解決策は私を幸せにしませんでした。

一言で言えば、コミットされたnode_modulesはリポジトリにあまりにも多くのノイズを追加します。
そして、shrinkwrap.jsonは管理が容易ではなく、シュリンクラップされたプロジェクトが数年で完成するという保証はありません。

私は、Mozillaが彼らのプロジェクトの1つに別のリポジトリを使っていたことを知りました https://github.com/mozilla-b2g/gaia-node-modules

そのため、ノードCLIツールでこのアイデアを実装するのにそれほど時間はかかりませんでした https://github.com/bestander/npm-git-lock

すべてのビルドが追加される直前に
npm-git-lock --repo [[email protected]：あなたの/ dedicated/node_modules/git/repository.git]

それはあなたのpackage.jsonのハッシュを計算し、リモートレポジトリからnode_modulesの内容をチェックアウトするか、あるいはこのpackage.jsonの最初のビルドであれば、きれいなnpm installを行い、結果をリモートレポジトリにプッシュします。

8
bestander

私にとってうまくいったのは、package.json（ "npm"： "1.1.x"）にnpmバージョンを明示的に追加し、gitにnode_modulesをチェックインしないことでした。毎回パッケージをダウンロードするのでデプロイは遅くなるかもしれませんが、チェックインしたときにパッケージをコンパイルすることができませんでした。Herokuは自分のローカルボックスにしか存在しないファイルを探していました。

5
Jason Griffin

Node_modulesをチェックインする代わりに、アプリケーション用のpackage.jsonファイルを作成してください。

Package.jsonファイルは、アプリケーションの依存関係を指定します。 Herokuは、npmにこれらの依存関係をすべてインストールするように指示することができます。リンクしたチュートリアルには、package.jsonファイルに関するセクションがあります。

3
matzahboy

から https://web.archive.org/web/20150212165006/http://www.futurealoof.com/posts/nodemodules-in-git.html ：

編集：元のリンクはこれ です が、現在は無効です。指摘してくれてありがとう@Flavio。

要点をまとめると。

  • デプロイするアプリケーションのnode_modulesのみをチェックインし、メンテナンスする再利用可能なパッケージはチェックインしないでください。
  • コンパイルされた依存関係は、コンパイル対象ではなくソースをチェックインし、デプロイ時に$ npmを再構築する必要があります。

私の好きなところ：

あなたのgitignoreにnode_moduleを追加したすべての人、、そのたわごとを削除してください、今日、これは残すことができない時代の成果物ですグローバルモジュールの時代は終わりました。

3
Benjamin Crouzier

私はこの解決策を使っています：

  1. node_modulesを保持する別のリポジトリを作成してください。特定のプラットフォーム用にビルドする必要があるネイティブモジュールがある場合は、プラットフォームごとに別々のリポジトリを作成します。
  2. git submoduleを使用してこれらのリポジトリをプロジェクトリポジトリに添付します。

git submodule add .../your_project_node_modules_windows.git node_modules_windows

git submodule add .../your_project_node_modules_linux_x86_64 node_modules_linux_x86_64

  1. プラットフォーム固有のnode_modulesからnode_modulesディレクトリへのリンクを作成し、node_modulesを.gitignoreに追加します。
  2. npm installを実行してください。
  3. サブモジュールリポジトリの変更をコミットします。
  4. プロジェクトリポジトリの変更を確定します。

そのため、さまざまなプラットフォームでnode_modulesを簡単に切り替えることができます（たとえば、OS Xで開発してLinuxにデプロイする場合など）。

3
mixel

http://nodejs.org/api/modules.html

[...]ノードは現在のモジュールの親ディレクトリから始まり、/node_modulesを追加し、その場所からモジュールをロードしようとします。

そこに見つからない場合、ツリーのルートに達するまで親ディレクトリに移動します。

あなたのアプリケーションに固有のあなた自身のモジュールを転がしているなら、あなたはあなたのアプリケーションの/node_modulesにそれらを（そしてそれらだけ）を保持することができます。そして、他のすべての依存関係を親ディレクトリに移動します。

この素晴らしいユースケースは、あなたがあなたのアプリケーションのためにあなたのアプリケーションのために特別に作成したモジュールをあなたがあなたのアプリケーションとうまく保つことを可能にし、そして後でインストールできる依存関係であなたのアプリケーションを散らかしません。

2
laggingreflex

シナリオ1：

1つのシナリオ：npmから削除されるパッケージを使用します。 node_modulesフォルダーにすべてのモジュールがある場合、それは問題になりません。 package.jsonにのみパッケージ名がある場合、それを取得することはできません。パッケージが24時間未満の場合、npmから簡単に削除できます。 24時間以上経過している場合は、連絡する必要があります。しかし：

サポートに連絡する場合、パッケージのそのバージョンを削除すると他のインストールが壊れるかどうかを確認します。その場合、削除しません。

続きを読む

そのため、この可能性は低いですが、シナリオ2があります...

シナリオ2：

これが当てはまる別のシナリオ：ソフトウェアまたは非常に重要なソフトウェアのエンタープライズバージョンを開発し、package.jsonに記述します。

"dependencies": {
    "studpid-package": "~1.0.1"
}

そのパッケージのfunction1(x)メソッドを使用します。

現在、studpid-packageの開発者はメソッドの名前をfunction1(x)to function2(x)に変更し、障害を起こします...パッケージのバージョンを1.0.1から1.1.0に変更します。これは問題です。次回npm installを呼び出すときに、チルダ（1.1.0）を使用したため、バージョン"studpid-package": "~1.0.1"を受け入れることになります。

function1(x)を呼び出すと、エラーや問題が発生する可能性があります。

Node_modulesフォルダー全体（多くの場合100 MB以上）をリポジトリーにプッシュすると、メモリー領域が消費されます。数百MB（package.jsonおよびnode_modules）と比較して、数KB（package.jsonのみ）...考えてみてください。

あなたはそれをすることができた/それについて考えるべきである：

  • ソフトウェアは非常に重要です。

  • 何かが失敗するとお金がかかります。

  • npmレジストリを信頼していません。 npmは集中化されており、理論的にはシャットダウンできます。

次の場合、99.9％のケースでnode_modulesフォルダーを公開する必要はありません：

  • あなた自身のためにソフトウェアを開発します。

  • 何かをプログラムし、その結果をGitHubに公開したいだけです。他の誰かがそれに興味を持っているかもしれないからです。

Node_modulesをリポジトリーに入れたくない場合は、.gitignoreファイルを作成し、node_modules行を追加します。

1
ndsvw