web-dev-qa-db-ja.com

GruntDeployにローカルモジュールではなくグローバルNPMモジュールを使用させる方法

まず、私はnpmとうなり声にとても慣れていません。 Gruntを使用して出力ファイルをコンパイルおよび生成するプロジェクトがあります。 Gruntを使用して出力ファイルを生成するようにビルドサーバーをセットアップしようとしています。 TFSソース管理でWindowsを使用していますが、 260文字のパス制限 のため、grunt-bower-taskモジュールをソース管理にチェックインできません( 単独で使用するため)インストールされたパスに230文字 )。

プロジェクトディレクトリからnpm installを実行すると、正常に動作し、次の必要なモジュールがプロジェクトディレクトリのnode_modulesフォルダにインストールされます。

  • うなり声
  • grunt-bower-task
  • grunt-contrib-compass
  • grunt-contrib-connect
  • grunt-contrib-jshint
  • grunt-contrib-requirejs
  • grunt-contrib-watch

そして、プロジェクトディレクトリからgrunt deployを実行すると、すべてが期待どおりに機能します。

ビルドプロセスの一部としてnpm installを実行することもできますが、すべてのファイルをダウンロードするのに数分かかるため、実行したくないです。また、ビルドが利用可能な外部Webサービスに依存することを望んでいません。

モジュールはローカルまたはグローバルにインストールできます なので、モジュールをビルドサーバーにグローバルにインストールして、node_modulesに配置する必要がないようにしたいと考えています。実行する前にプロジェクトディレクトリ内に直接フォルダgrunt deploynpm 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"
  }
}

ありがとう。

27
deadlydog

同様の結果を得るには、npmのグローバルオプションを使用する代わりに、モジュールで シンボリックリンク を使用する必要があります。

グローバルnpmインストールは、jshintgrunt-cliなどのコマンドラインユーティリティの便宜のためにのみ意図されています。

7
bevacqua

回避策:すべての一時的な依存関係を独自の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ツリーになります。

16
jasonkarns

このスレッドは古いことは知っていますが、ついにMacを使って自分の個人的な答えを見つけましたが、PCでも同じことが言えると思います。

bevacquaの次の回答をフォローアップする:

同様の結果を得るには、npmのグローバルオプションを使用する代わりに、モジュールでシンボリックリンクを使用する必要があります。

グローバルnpmインストールは、jshintやgrunt-cliなどのコマンドラインユーティリティの便宜のためにのみ意図されています。

私はいくつか掘り下げて、もう少し明確にすることができるかもしれません:

最終的に、ユーザーディレクトリのルートにグローバルフォルダを作成しました。そのディレクトリ内に、npm installを使用して必要なすべてのパッケージを追加しました。たとえば、npm install gruntnpm install grunt-contrib-watchnpm 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モジュールを必要とするプロジェクトがあるときはいつでも、グローバルディレクトリからインストールするだけで、シンボリックリンクが作成されたすべての場所で利用できるようになります。

4
Michael Scherr

私は fenestrate を使用して、Windowsでこの種の問題を解決します。 Gitで動作する場合でも、チームエクスプローラー内でVisual StudioからGit統合を使用すると、長いファイルパスがnode_modulesフォルダーにある場合、そのフォルダーをソース管理に追加していなくてもクラッシュします。

通常、GruntとBowerの依存関係構造がこれを引き起こします。

  1. 私が最初にお勧めするのは、パッケージでnpm dedupeを実行することです。これは、すでにインストールされているパッケージをスキャンして、いくつかの依存関係が重複していないかどうかを確認することです。より高いレベルで見つかった場合は、深くテストされたものを削除します。

  2. 次に、重複排除で問題が解決しない場合、この問題の原因となっている非常に深くネストされた依存関係を見つけた場合は、それをソリューションに直接インストールして、重複排除を再実行してください。

  3. これを引き起こすパッケージの依存関係が他にもある場合は、 fenestrate で問題が解決します。さらに、npm installにフックでき、新しいパッケージがインストールされた後は常に実行されるため、非常に便利です。また、完全にリバーシブルです。

これがお役に立てば幸いです。

4
alex.g

Npmリンクが十分でない場合(ネットワークファイルシステムなど)、 'requireg' パッケージを使用できます。これは、どういうわけかそれを「組み込み」にする唯一のクリーンなソリューションです。 'requireg'パッケージには、グローバル化する関数があり、後続のrequire呼び出しもグローバルに検索されます。

0
xamiro