まず、私はnpmとうなり声にとても慣れていません。 Gruntを使用して出力ファイルをコンパイルおよび生成するプロジェクトがあります。 Gruntを使用して出力ファイルを生成するようにビルドサーバーをセットアップしようとしています。 TFSソース管理でWindowsを使用していますが、 260文字のパス制限 のため、grunt-bower-taskモジュールをソース管理にチェックインできません( 単独で使用するため)インストールされたパスに230文字 )。
プロジェクトディレクトリからnpm installを実行すると、正常に動作し、次の必要なモジュールがプロジェクトディレクトリのnode_modulesフォルダにインストールされます。
そして、プロジェクトディレクトリからgrunt deployを実行すると、すべてが期待どおりに機能します。
ビルドプロセスの一部としてnpm installを実行することもできますが、すべてのファイルをダウンロードするのに数分かかるため、実行したくないです。また、ビルドが利用可能な外部Webサービスに依存することを望んでいません。
モジュールはローカルまたはグローバルにインストールできます なので、モジュールをビルドサーバーにグローバルにインストールして、node_modulesに配置する必要がないようにしたいと考えています。実行する前にプロジェクトディレクトリ内に直接フォルダgrunt deploy。 npm install -g、およびnpm install -g [module]上記の各モジュール、およびnpm install -g grunt-cli。
npm prefix -gを実行すると、グローバルモジュールディレクトリがC:\ Users [My User ]\AppData\Roaming\npm、そしてそのディレクトリのnode_modulesフォルダーを見ると、すべてのモジュールが表示されます。ただし、grunt deployを実行すると、次のように文句が表示されます。
致命的なエラー:ローカルのうなり声が見つかりません
* node_modules\grunt *ディレクトリだけを含めると、次のエラーが発生します。
ローカルNpmモジュール「grunt-contrib-watch」が見つかりません。インストールされていますか?
ローカルNpmモジュール「grunt-contrib-jshint」が見つかりません。インストールされていますか?
.。
* grunt deploy --base "C:\ Users [My User]\AppData\Roaming\npm"も使用してみましたが、.jshintrcなどの他のファイルが見つからないと文句を言います。
それで、プロジェクトディレクトリを調べるのではなく、grunt deployを実行して、モジュールのnpmグローバルプレフィックスパスをチェックする方法はありますか?
厄介な回避策は、ビルドプロセス中にモジュールをローカルプロジェクトディレクトリに手動でコピーすることですが、可能であればこれを避けたいと思います。
参考までに、これは私のpackage.jsonファイルがどのように見えるかです:
{
"name": "MyProject",
"version": "0.0.1",
"scripts": {
"preinstall": "npm i -g grunt-cli bower"
},
"devDependencies": {
"grunt": "~0.4.1",
"grunt-contrib-compass": "~0.2.0",
"grunt-contrib-watch": "~0.4.4",
"grunt-contrib-jshint": "~0.6.0",
"grunt-contrib-requirejs": "~0.4.1",
"grunt-contrib-connect": "~0.3.0",
"grunt-bower-task": "~0.2.3"
}
}
ありがとう。
同様の結果を得るには、npm
のグローバルオプションを使用する代わりに、モジュールで シンボリックリンク を使用する必要があります。
グローバルnpm
インストールは、jshint
やgrunt-cli
などのコマンドラインユーティリティの便宜のためにのみ意図されています。
回避策:すべての一時的な依存関係を独自のpackage.jsonに明示的にリストします。
たとえば、module_aに依存していて、module_aがmodule_bに依存しているとします。 npmはmodule_bをmodule_aのローカルにインストールするため、npm install
の後にnode_modules/module_a/node_modules/module_b/
があります。ただし、your package.jsonに直接依存関係としてmodule_bを追加した場合(およびバージョン指定子が完全に一致した場合)、npmはmodule_bをトップレベルで1回だけインストールします。
これは、モジュールが必要な場合、モジュールは最も近いnode_modulesディレクトリを探し始め、必要なモジュールが見つかるまで上方向にトラバースするためです。したがって、npmは、バージョンが一致する最下位レベルにモジュールをインストールするだけで、ディスク領域を節約できます。
だから、修正された例。 [email protected]に依存する[email protected]に依存します。 [email protected]にも依存している場合は、module_bが2回インストールされることになります。 (バージョン0.1.0はトップレベルにインストールされ、0.2.0はmodule_aの下にインストールされます。)ただし、v0.2.0に依存している場合(module_aが使用するようにpackage.jsonの正確なバージョン文字列を使用)、 npmは、同じバージョンのmodule_bを使用できることに気付くでしょう。したがって、module_bはトップレベルにのみインストールされ、not module_aの下にインストールされます。
簡単に言うと、深いモジュールツリーを持つ一時的な依存関係を自分のpackage.jsonに直接追加すると、より浅いnode_modules
ツリーになります。
このスレッドは古いことは知っていますが、ついにMacを使って自分の個人的な答えを見つけましたが、PCでも同じことが言えると思います。
bevacquaの次の回答をフォローアップする:
同様の結果を得るには、npmのグローバルオプションを使用する代わりに、モジュールでシンボリックリンクを使用する必要があります。
グローバルnpmインストールは、jshintやgrunt-cliなどのコマンドラインユーティリティの便宜のためにのみ意図されています。
私はいくつか掘り下げて、もう少し明確にすることができるかもしれません:
最終的に、ユーザーディレクトリのルートにグローバルフォルダを作成しました。そのディレクトリ内に、npm install
を使用して必要なすべてのパッケージを追加しました。たとえば、npm install grunt
、npm install grunt-contrib-watch
、npm install grunt-contrib-less
などを実行しました。同じフォルダにpackage.json
ファイルを追加し、npm install
を実行して追加することもできます。それらすべてを一度に。これで、私のグローバルディレクトリは次の構造になりました。
.global_grunt_modules
node_modules
grunt
grunt-contrib-watch
grunt-contrib-less
次に、gruntを実行する必要がある作業中のプロジェクトディレクトリに移動し、そのフォルダのルートで次のコマンドを実行しました。
ln -s ~/.global_grunt_modules/node_modules .
-s
(シンボリックリンク)フラグを指定したln
は、次の2つの引数を取ります。
[source_file] [target_dir]
したがって、コマンドは基本的に「グローバルnode_modulesフォルダーからシンボリックリンクを作成し、それを現在のディレクトリにリンクする」と言います。 .
は、現在の作業ディレクトリを指定します。
これがお役に立てば幸いです。私も問題を抱えていました。次に、新しいgruntモジュールを必要とするプロジェクトがあるときはいつでも、グローバルディレクトリからインストールするだけで、シンボリックリンクが作成されたすべての場所で利用できるようになります。
私は fenestrate を使用して、Windowsでこの種の問題を解決します。 Gitで動作する場合でも、チームエクスプローラー内でVisual StudioからGit統合を使用すると、長いファイルパスがnode_modulesフォルダーにある場合、そのフォルダーをソース管理に追加していなくてもクラッシュします。
通常、GruntとBowerの依存関係構造がこれを引き起こします。
私が最初にお勧めするのは、パッケージでnpm dedupe
を実行することです。これは、すでにインストールされているパッケージをスキャンして、いくつかの依存関係が重複していないかどうかを確認することです。より高いレベルで見つかった場合は、深くテストされたものを削除します。
次に、重複排除で問題が解決しない場合、この問題の原因となっている非常に深くネストされた依存関係を見つけた場合は、それをソリューションに直接インストールして、重複排除を再実行してください。
これを引き起こすパッケージの依存関係が他にもある場合は、 fenestrate で問題が解決します。さらに、npm installにフックでき、新しいパッケージがインストールされた後は常に実行されるため、非常に便利です。また、完全にリバーシブルです。
これがお役に立てば幸いです。
Npmリンクが十分でない場合(ネットワークファイルシステムなど)、 'requireg' パッケージを使用できます。これは、どういうわけかそれを「組み込み」にする唯一のクリーンなソリューションです。 'requireg'パッケージには、グローバル化する関数があり、後続のrequire呼び出しもグローバルに検索されます。