Nvm-windows: nvm ne fonctionne pas dans les situations 32/64 bits pour Windows 7

Créé le 18 juil. 2016 · 10Commentaires · Source: coreybutler/nvm-windows

Mon environnement

[X] Windows 7 ou inférieur (pas vraiment pris en charge en raison de EOL)
[ ] Windows 8
[ ] Windows 8.1
[] Windows 10
[] Windows 10 IoT Core
[] Windows Server 2012
[] Windows Server 2012 R2
[] Windows Server 2016
[] Mon installation Windows n'est pas en anglais.
J'ai déjà...
[X] lisez le README pour être au courant des problèmes de npm et d'antivirus.
[X] a examiné le wiki pour s'assurer que mon problème n'a pas déjà été résolu.
[X] a vérifié que j'utilise un compte avec des privilèges administratifs.
[X] a recherché les problèmes (ouverts et fermés) pour s'assurer qu'il ne s'agissait pas d'un doublon.
[X] s'est assuré qu'il ne s'agissait pas d'une question sur la façon d'utiliser NVM pour Windows, puisque
Mon problème est lié à (cochez uniquement ceux qui s'appliquent):
[] settings.txt
[] prise en charge du proxy
[X] Prise en charge 32 ou 64 bits
Comportement prévisible

J'utilise Windows 7/64 bits
J'ai installé (avec admin priv) la NVM pour Windows 1.1.1. De là, j'ai utilisé

nvm install 6.1.0 all
nvm install 6.3.0 all

J'ai alors appelé
nvm list
résultant en

C:\Users\kagentes>nvm list
    6.3.0
    6.1.0

J'ai ensuite couru
nvm use 6.3.0 64

et alors
node -v
et devrait obtenir
v6.3.0

Comportement réel

En courant
node -v
Je reçois

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

Même après avoir défini la commande nvm use, je note que la liste ne semble pas confirmer que la commande "use" fonctionne. Un péché:

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

D'après les captures d'écran de la page https://github.com/coreybutler/nvm-windows , je crois que la commande nvm list devrait renvoyer quelque chose comme ça ci-dessous (mais je ne l'obtiens PAS )

C:\Users\kagentes>nvm list

*   6.3.0 (In Use)
    6.1.0

Il n'a pas d'astérisque ou d'indicateur «en cours d'utilisation».

Cela aidera peut-être également à diagnostiquer le problème, mais lorsque j'exécute la commande nvm arch j'obtiens les résultats étranges suivants, indépendamment de ce que j'ai défini dans nvm use :

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

Étapes pour reproduire le problème:

Les étapes pour reproduire sont déjà données dans la section sur le comportement attendu ci-dessus. J'ai déjà essayé des recommandations possibles dans d'autres problèmes, tels que le problème n ° 146, ainsi que le redémarrage du shell, le redémarrage de l'ordinateur et l'assurance que tout a été fait avec les privilèges d'administrateur. Avant de commencer tout cela, j'ai désinstallé les versions précédentes de Node qui se trouvaient sur l'ordinateur. (puis installé nvm-windows et suivi vos instructions).

help wanted

Source

corvinrok

Commentaire le plus utile

@kgentes - Je suppose qu'avant nvm, vous avez installé la version 64 bits de node et installé nvm en utilisant les valeurs par défaut.

Après avoir désinstallé le nœud, assurez-vous que le répertoire dans lequel le nœud a été installé à l'origine a été supprimé et pas seulement vide. Pour Windows 7, 64 bits, la valeur par défaut est "C: Program Filesnodejs".

Si le répertoire "nodejs" existe toujours, la commande "nvm use" ne peut pas faire le lien symbolique vers la version du nœud sous le contrôle de nvm.

J'ai eu le même problème jusqu'à ce que je supprime manuellement le répertoire "nodejs".

J'espère que ça t'as aidé

pleverett le 19 juil. 2016

👍13 🎉5 😄4 ❤2

Tous les 10 commentaires

Désolé de poser la question évidente, mais avez-vous essayé de redémarrer la fenêtre du terminal? Sur Win7, il s'étouffe parfois encore la première fois que vous essayez d'utiliser une version spécifique (mklink).

coreybutler le 18 juil. 2016

Oui je l'ai fait. J'ai essayé de redémarrer la fenêtre du terminal .. puis même la machine .. ni changé le résultat.

corvinrok le 18 juil. 2016

OK - J'examinerai ceci si j'ai le temps. Malheureusement, Win7 n'est pas quelque chose que je vois souvent.

coreybutler le 18 juil. 2016

A tous, pour référence concernant Win7: https://github.com/coreybutler/nvm-windows/wiki/Support-for-Windows-7-and-Earlier

coreybutler le 18 juil. 2016

@kgentes - Je suppose qu'avant nvm, vous avez installé la version 64 bits de node et installé nvm en utilisant les valeurs par défaut.

Si le répertoire "nodejs" existe toujours, la commande "nvm use" ne peut pas faire le lien symbolique vers la version du nœud sous le contrôle de nvm.

J'ai eu le même problème jusqu'à ce que je supprime manuellement le répertoire "nodejs".

J'espère que ça t'as aidé

pleverett le 19 juil. 2016

👍13 🎉5 😄4 ❤2

Merci @pleverett .. J'essaierai ça bientôt .. apprécie la tête haute.

corvinrok le 20 juil. 2016

@pleverett MERCI MONSIEUR! Cela a fonctionné comme vous l'avez annoncé! Superlike! Ce sujet peut être clos. Devrait probablement être marqué comme une solution (je ne sais pas si c'est quelque chose qui peut être fait, ici, je suis nouveau dans cet écosystème) pour les futurs utilisateurs de Windows 7 qui pourraient rencontrer ce problème. NVM pour Windows fonctionne maintenant de manière transparente, une fois que j'ai supprimé le répertoire "C: Program Filesnodejs" ("C: Program Files (x86) nodejs" pour 32 bits) qui apparemment n'est pas supprimé par défaut du programme de désinstallation. Avec ce répertoire, j'ai également supprimé:
- "C: UsersusernameAppDataRoamingnpm"
- "C: UsersusernameAppDataRoamingnpm-cache"

Bien que ce ne soit probablement pas nécessaire.

Quoi qu'il en soit, tout fonctionne. Merci!

corvinrok le 21 juil. 2016

@pleverett @coreybutler

un autre problème connexe ---
maintenant que je peux voir et changer les versions de node via nvm, je me demande si je devrais voir des résultats différents lorsque je fais le:

npm config list

Pour le moment, aucune des informations à l'exception de la variable ci-dessous ne change.
user-agent = "npm/3.10.3 node/v6.3.0 win32 ia32"

tous les autres restent les mêmes. Et il semble qu'il n'existe qu'une seule version des modules de nœuds installés globalement.

si je passe uniquement de la version 64 bits de 6.3.0 à la version 32 bits de 6.3.0, aurai-je les mêmes installations de modules de nœuds globaux? ou en fera-t-il des distincts? Ou dois-je effectuer une modification de version pour obtenir un ensemble différent de modules de nœuds installés globalement? Idéalement, je pense que cela garderait un contexte unique pour chaque version de bit (à cause des modules de nœuds natifs comme libxml - ??? etc), mais je peux voir pourquoi d'autres pourraient ne pas aimer que cela fonctionne de cette façon.

Est-ce que je l'utilise toujours mal? ou est-ce un bug lié?

corvinrok le 22 juil. 2016

comme cela fonctionne toujours sur le même fil, je voulais le rouvrir plutôt que de créer un nouveau problème ... [voir le commentaire précédent pour mon statut mis à jour]

corvinrok le 22 juil. 2016

@kgentes - Je suis désolé d'avoir manqué ça ... ça devrait probablement être un problème différent.

Si vous passez uniquement de 32 à 64 bits ou vice versa, NVM4W utilisera le même répertoire global node_modules . Cela a été fait intentionnellement, principalement pour réduire au minimum l'empreinte globale de l'environnement Node. Avoir des répertoires d'installation séparés pour les deux 32/64 bits doublera l'empreinte de la plupart des utilisateurs ... et l'empreinte globale est quelque chose à laquelle la plupart des utilisateurs ne pensent même pas jusqu'à ce qu'ils manquent d'espace. Malgré cela, je penche de toute façon vers l'utilisation d'un répertoire d'installation individuel par version + architecture proc. Cela devrait vraiment appartenir à l'utilisateur, et comme vous l'avez dit, cela casse certains packages natifs.

Je termine cela car le sujet est un peu différent. N'hésitez pas à ouvrir un nouveau numéro si vous le souhaitez.

coreybutler le 3 nov. 2016

Cette page vous a été utile?

0 / 5 - 0 notes