Nvm-windows: インストールフォルダが正しくありません

私は間違っていますか、それともNVMは400MBのノードパッケージキャッシュを移動プロファイルに入れただけですか？

いいえ、それはNPMのバグです。

デフォルトのインストールは、ローミングではなく、ローカルユーザーのappdataディレクトリを指します。 実行可能ファイルを別の場所に配置する方がよい場合もありますが、すべてのノードインストールファイルとnpmはNVMのデータと見なされます（これはnpmの設計です）。 繰り返しますが、これらは理由によるデフォルトです...気に入らない場合は変更できます。

400MBをどこから取得しているのかわかりません。 ご使用の環境について詳しく教えてください。

最初の点で、おそらく違いは、私がドメインに接続されたコンピューターにインストールしているのに、あなたはインストールしていないということです。 しかし、いずれにしてもそれはまだ間違っています。 AppDataはユーザー設定用であり、実行可能ファイル用ではありません。

2つ目のポイントは、ノード自体がその間違いを犯していることです。 個別にバグを報告します。

これは必ずしも「間違っている」わけではありませんが、悪影響がある場合は、ユースケースを検討させていただきます。 ドメインに接続されたコンピューターで同じ経験をしたことはありませんでした。そのため、環境の詳細は、特定のユースケースを理解するのに役立ちます。

たとえば、何を探すべきかがわかっている場合は、インストーラーの次のバージョンをドメイン対応にすることができます。 言い換えれば、デフォルトのインストール場所はよりスマートである可能性があります。

ベースラインの推奨事項は次のとおりです。

• プログラムは%ProgramFiles%に入ります。これは通常、 C:\Program Filesです。
• 64ビットマシンでは、古いx86プログラムは%ProgramFiles(x86)%に入ります。これは通常、 C:\Program Files (x86)です。
• パッケージキャッシュなどのマシン全体のプログラムデータは、 %ProgramData%に格納されます。これは通常、 C:\ProgramData
• マシン間を安全にローミングできるユーザー設定は%APPDATA%
• 特定のマシンにローカルなユーザー設定（インストールパスを含むものなど）は、 %LOCALAPPDATA%ます。

実行可能ファイルがappdataにあることは珍しいことではありません。 clickonceを使用してインストールされたアプリケーションは、Microsoft製のインストーラーです。 Chromeはそれを行います。 多くのことがそれを行います。

@aljones主な理由の1つは、これです。ユーザープロファイルにプログラムをインストールすると便利な場合がありますが、どのプロセスでも自由に変更できるという点で、セキュリティに間違いなく影響します。 ClickOnceはユーザープロファイルにインストールされますが、アセンブリがシステムに対して持つ特権が少なくなることも保証することに注意してください。

管理者権限を必要とせずにユーザーごとにアプリケーションをインストールする一般的なユースケースがありますが、これは非常に貧弱なデフォルトの動作であり、Chromeはここで悪い前例を設定します。

私のごく最近の経験は議論に関連していると思います：私は最近ワークステーションスイッチを持っていました。 移動プロファイル内のnode_packagesのパスが非常に深いため、node_packagesフォルダーを爆破するまで、マシンが実行しようとした移動プロファイルの復元は毎回失敗していました。 これらのエラーは、Windowsイベントログに表示されます。 それを行った後、新しいワークステーションは最終的に移動プロファイルを同期できるようになりました。

ネットワーク内で使用するためにプロファイルをバックアップする会社で作業する場合、ローミングにインストールすると問題が発生することに同意します。 たとえば、コンピュータのシャットダウンには30分、再起動には30分かかります。 すべてnpmモジュールによるものです。 残念ながら、AFAIK、これはNPM自体の問題です。

これのフォローアップとして：

一般に、バージョンマネージャーはプログラムを管理しているだけであることに注意することが重要です。 前のコメントを繰り返します。NVMの意味では、インストールされたプログラム（ノード）はデータです。 それをどのように使用するか（つまり、npmモジュール）は、フットプリントに寄与する可能性があります。

@ sam3kは、フットプリントがnpmの設計方法に確実に関連していることは正しいです。また、これに対してNVMが行うべきことはあまりなく、npm自体がこれに対して行うこともできません。 要するに、何をインストールしているのかを知ることであり、あらゆる種類のパッケージマネージャーを使用すると、これを当然のことと考えるのが簡単になります。 多くの人々は、モジュールのフットプリントに注意を払っていません。これは、オープンソースの世界に固有のコード/環境の品質の問題です。 結論として、規律あるコーディング手法を通じてこの問題を解決するのはコミュニティ次第です（簡単な作業とはほど遠い）。 私はこれを提唱している多くの人の1人です（ npmにはパーソナルトレーナーが必要です。ポイント：npm管理は、実行しているノードのバージョンを管理するという基本的な前提を超えています。

@aljonesと@ygraの両方に良い点があります。 私はそれらに同意しませんが、シンボリックリンクを機能させるためには管理者権限が必要であることを皆さんに思い出させたいと思います。 これは、NVM forWindowsの動作の基本原則です。

@cokobwareには、エンタープライズ環境で一般的な問題であると私が信じているものがあります。 肝心なのは、npmは大規模な移植を容易にするために設計されたものではないということです。 node + npmの1つのインスタンスは、複数のバージョンを追加することは言うまでもなく、すでにかなり重いです。 データ/ファイルがワークステーションからワークステーションにどのように移動するかに関係なく、それらの多くは非常に多く、しばらく時間がかかるでしょう。 オプションは、Windowsの移動プロファイルを使用するか、すべてを圧縮して手動で転送するか、npmレジストリから再ダウンロードすることです。 どのように回転させても、ワークステーションの同期には、すべてのビットを適切な場所に配置するのに時間がかかります。

NVM for Windowsの将来（現在）は、ノードバージョンの切り替えに引き続き焦点を当てる可能性があります。 それを反映するためにプロジェクト名を変更することもあります。 インストーラーに一般的なデフォルトを提供し続けますが、組織に適した方法でこれらのデフォルトをオーバーライドするのは組織/開発者の責任です。 NVM4Wがより良いnpm管理のためのフックを提供できる方法を実験していますが、ノードバージョン管理はnpmフットプリント管理とは明らかに異なる問題だと思います。

@Grauenwolfの提案とこれらのリファレンスに従ってください：デプロイメントガイド、 CSIDLおよび環境変数

• ％USERPROFILE％AppDataを％PROGRAMFILES％または％PROGRAMFILES（X86）％にシンボリックリンクすることはお勧めできません。 マルチユーザーの問題（所有権の問題。他のユーザーはリンクにアクセスできません）。
• プログラムnvmは、％PROGRAMFILES％または％PROGRAMFILES（X86）％に格納されていると想定しています。
• スコープはすべてのユーザーであるため、nodejsesリポジトリは％PROGRAMDATA％に格納されることになっています。
• スコープはユーザーごとであるため、アクティブなnodejsリンクは％LOCALAPPDATA％に格納されることになっています。

他のバグのため、NVMを％PROGRAMFILES％にインストールできません。 名前にスペースが含まれているフォルダーに配置すると、インストールコマンドは失敗します。