Nvm-windows: Windows7の32/64ビットの状況でnvmが機能しない

作成日 2016年07月18日  ·  10コメント  ·  ソース: coreybutler/nvm-windows

私の環境

  • [X] Windows 7以下(EOLのため、実際にはサポートされていません)
  • [ ] ウィンドウズ8
  • [] Windows 8.1
  • [ ] ウィンドウズ10
  • [] Windows 10 IoT Core
  • [] Windows Server 2012
  • [] Windows Server 2012 R2
  • [] Windows Server 2016
  • []私のWindowsインストールは英語以外です。

    私はすでに...

  • [X] READMEを読んで、npmの落とし穴とウイルス対策の問題に注意してください。

  • [X] wikiをレビューして、私の問題がまだ解決されていないことを確認しました。
  • [X]管理者権限を持つアカウントを使用していることを確認しました。
  • [X]は問題(オープンとクローズ)を検索して、これが重複していないことを確認しました。
  • [X]は、質問やコメントにgitterが使用されるため、forWindowsの使用方法に関する質問ではないことを確認しました。

    私の問題は関連しています(該当するものだけをチェックしてください):

  • [] settings.txt

  • []プロキシサポート
  • [X] 32ビットまたは64ビットのサポート

    予想される行動

私はWindows7 / 64ビットを実行しています
NVM for Windows 1.1.1を(admin privで)インストールしました。 そこから、私は使用しました

nvm install 6.1.0 all
nvm install 6.3.0 all

それから私は電話しました
nvm list
その結果

C:\Users\kagentes>nvm list
    6.3.0
    6.1.0

それから私は走った
nvm use 6.3.0 64

その後
node -v
と期待
v6.3.0

実際の動作

走っているとき
node -v
私は得る

'node' is not recognized as an internal or external command,
operable program or batch file.

また、nvm useコマンドを設定した後でも、リストには「use」コマンドが機能していることを確認していないようです。 のように:

C:\Users\kagentes>nvm use 6.3.0 64
Now using node v6.3.0 (64-bit)

C:\Users\kagentes>nvm list

    6.3.0
    6.1.0

https://github.com/coreybutler/nvm-windowsページのスクリーンショットから、 nvm listコマンドは以下のようなものを返すはずだと思います(しかし、私はこれを取得していません

C:\Users\kagentes>nvm list

*   6.3.0 (In Use)
    6.1.0

アスタリスクまたは「使用中」のインジケーターはありません。

おそらく、これは問題の診断にも役立ちますが、 nvm archコマンドを実行すると、 nvm use設定した内容に関係なく、次の奇妙な結果が得られます。

C:\Users\kagentes>nvm arch
System Default: 64-bit.
Currently Configured: -bit.

問題を再現する手順:

再現する手順は、上記の予想される動作のセクションにすでに記載されています。 シェルの再起動、コンピューターの再起動、すべてが管理者権限で行われることの保証だけでなく、問題#146などの他の問題で考えられる推奨事項をすでに試しました。 このすべてを開始する前に、コンピューター上にあった以前のバージョンのノードをアンインストールしました。 (次に、nvm-windowsをインストールし、指示に従いました)。

help wanted

最も参考になるコメント

@ kgentes -

ノードをアンインストールした後、ノードが最初にインストールされたディレクトリが空ではなく削除されていることを確認してください。 Windows 7、64ビットの場合、デフォルトは「C:ProgramFilesnodejs」です。

「nodejs」ディレクトリがまだ存在する場合、「nvmuse」コマンドはnvmの制御下にあるノードバージョンへのシンボリックリンクを作成できません。

「nodejs」ディレクトリを手動で削除するまで、同じ問題が発生しました。

それが役立つことを願っています

全てのコメント10件

明らかな質問をして申し訳ありませんが、ターミナルウィンドウを再起動してみましたか? Win7では、特定のバージョン(mklink)を初めて使用しようとしたときに、チョークが発生することがあります。

はい..私はしました。 ターミナルウィンドウを再起動してみましたが、マシンでも結果は変わりませんでした。

OK-時間があればこれを調べます。 残念ながら、Win7は私がよく使うものではありません。

すべての人に、Win7に関する参照: https

@ kgentes -

ノードをアンインストールした後、ノードが最初にインストールされたディレクトリが空ではなく削除されていることを確認してください。 Windows 7、64ビットの場合、デフォルトは「C:ProgramFilesnodejs」です。

「nodejs」ディレクトリがまだ存在する場合、「nvmuse」コマンドはnvmの制御下にあるノードバージョンへのシンボリックリンクを作成できません。

「nodejs」ディレクトリを手動で削除するまで、同じ問題が発生しました。

それが役立つことを願っています

ありがとう@pleverett ..私はすぐにそれを試してみます..頭を上げて感謝します。

@pleverettありがとうございます! これはあなたが宣伝したように機能しました! 超いいね! このスレッドは閉じることができます。 この問題が発生する可能性のある将来のWindows7ユーザーのために、おそらく解決策としてマークする必要があります(これが実行できるかどうかはわかりませんが、ここでは、このエコシステムは初めてです)。 NVM for Windowsは現在シームレスに動作しています。「C:ProgramFilesnodejs」(32ビットの場合は「C:ProgramFiles(x86)nodejs」)ディレクトリを削除すると、アンインストーラのデフォルトでは削除されないようです。 そのディレクトリに加えて、私も削除しました:
-「C:UsersusernameAppDataRoamingnpm」
-「C:UsersusernameAppDataRoamingnpm-キャッシュ」

それはおそらく必要ではありませんでしたが。

とにかく、すべてが機能しています。 ありがとう!

@pleverett @coreybutler

別の関連する問題---
nvmを介してノードのバージョンを表示および変更できるようになったので、:を実行すると異なる結果が表示されるのではないかと思います。

npm config list

現時点では、以下の1つの変数を除いて情報は変更されていません。
user-agent = "npm/3.10.3 node/v6.3.0 win32 ia32"

他のすべては同じままです。 また、グローバルにインストールされたノードモジュールのバージョンは1つしかないようです。

64ビットバージョンの6.3.0から32ビットバージョンの6.3.0にのみ変更する場合、同じグローバルノードモジュールをインストールできますか? それとも別のものになりますか? または、グローバルにインストールされたノードモジュールの異なるセットを取得するために、バージョンを変更する必要がありますか? 理想的には、ビットバージョンごとに一意のコンテキストを維持すると思いますが(libxml-???などのネイティブノードモジュールのため)、他の人がそのように機能することを好まない理由はわかります。

私はまだそれを間違って使用していますか? またはこれは関連するバグですか?

これはまだ同じスレッドで機能しているので、新しい問題を作成するのではなく、これを再度開きたいと思いました... [更新されたステータスについては、前のコメントを参照してください]

@ kgentes-申し訳ありませんが、これを見逃しました...おそらく別の問題になるはずです。

32-> 64ビットからのみ切り替える場合、またはその逆の場合、NVM4Wは同じグローバルnode_modulesディレクトリを使用します。 これは、主にノード環境の全体的なフットプリントを最小限に抑えるために意図的に行われました。 32/64ビットの両方に別々のインストールディレクトリがあると、ほとんどのユーザーのフットプリントが2倍になります...そして全体的なフットプリントは、ほとんどのユーザーがスペースを使い果たすまで考えさえしないものです。 それにもかかわらず、私はとにかくバージョン+ procアーキテクチャによって個別のインストールディレクトリを使用することに傾いています。 それは本当にユーザー次第であるはずです、そしてあなたが言ったように、これはいくつかのネイティブパッケージを壊します。

件名が少し違うので締めくくります。 よろしければ、お気軽に新しい号を開いてください。

このページは役に立ちましたか?
0 / 5 - 0 評価