5
votes

Sous-système Windows pour Linux (WSL) utilisant l'installation partagée de Node.js avec Windows: les binaires Node.js npm et npx ne fonctionnent pas

J'ai récemment migré vers un environnement Windows + WSL (WSL va très bien d'ailleurs). La principale raison de faire cela est d'avoir un environnement Linux pour le développement et d'avoir Windows pour d'autres applications et jeux sans avoir à redémarrer mon ordinateur (avait une configuration à double démarrage auparavant).

Dans le processus d'installation, j'ai trouvé la plupart des les binaires installés par Windows peuvent être exécutés à partir de WSL. Donc, au lieu de dupliquer les installations (par exemple: installer java et maven dans Windows afin d'utiliser Eclipse IDE, puis l'installer séparément dans WSL pour l'utiliser dans le terminal), je pourrais simplement installer java jdk dans Windows et lier les binaires à WSL dans l'ordre pour partager l'installation de jdk, cela a fonctionné parfaitement). Mais en faisant de même avec node, il arrive que les binaires node npm et npx ne fonctionnent pas :(

Je souhaitais avoir une installation de nœud unique que je pourrais gérer en utilisant nvm windows . J'ai donc commencé l'installation de la manière suivante:

Dans WSL, j'ai configuré mon /etc/wsl.conf , suivant Guide de Nick Janetakis ici (merci Nick ) afin de monter Windows conduit à / au lieu de /mnt/

/etc/wsl.conf

user@host:~$ npm -v
internal/modules/cjs/loader.js:583
throw err;
^

Error: Cannot find module 'C:\home\user\bin\node_modules\npm\bin\npm-cli.js'
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:581:15)
at Function.Module._load (internal/modules/cjs/loader.js:507:25)
at Function.Module.runMain (internal/modules/cjs/loader.js:742:12)
at startup (internal/bootstrap/node.js:283:19)
at bootstrapNodeJSCore (internal/bootstrap/node.js:743:3)

Puis installé le nœud dans Windows:

user@host:/d/tmp$ node -v
v10.15.0
user@host:/d/tmp$ echo "console.log('Hello World');" >> index.js
user@host:/d/tmp$ node index.js
Hello World

Tout fonctionne comme prévu jusqu'à présent. L'étape suivante consiste à créer un lien symbolique entre les binaires du nœud Windows et WSL. Les binaires se trouvent à: p>

user@host:~$ mkdir ~/bin
user@host:~$ ln -s /c/Program\ Files/nodejs/node.exe ~/bin/node
user@host:~$ ln -s /c/Program\ Files/nodejs/npm ~/bin/npm
user@host:~$ ln -s /c/Program\ Files/nodejs/npx ~/bin/npx

Donc à l'intérieur du terminal WSL (rappelez-vous que mon di sks sont montés sur / c pas / mnt / c comme comportement par défaut):

C:\Windows\system32> where node
C:\Program Files\nodejs\node.exe

C:\Windows\system32> where npm
C:\Program Files\nodejs\npm
C:\Program Files\nodejs\npm.cmd

C:\Windows\system32>where npx
C:\Program Files\nodejs\npx
C:\Program Files\nodejs\npx.cmd

Et ...

C:\Windows\system32> nvm install 10.15.0
... installing process...
C:\Windows\system32> nvm use 10.15.0
...success message...
C:\Windows\system32> node -v
v10.15.0
C:\Windows\system32> npm -v
6.4.1

Génial! ( Remarque: comme le nœud est installé sur Windows, lorsque vous êtes sur WSL, vous devez l'utiliser dans un lecteur de disque, / d dans ce cas). Mais ...

[automount]
root = /
options = "metadata"

Voilà la raison pour laquelle j'écris ceci. L'erreur est claire, npm essaie de trouver npm-cli.js dans un chemin qui est un mélange câblé de l'emplacement du lien symbolique npm à l'intérieur d'un chemin Windows.

Existe-t-il un moyen de dire à npm / npx le correct chemin Windows où il doit trouver ses fichiers à partir de WSL?

Désolé pour la longue question mais en raison de la configuration très particulière, j'ai considéré cette contextualisation nécessaire.


0 commentaires

3 Réponses :


0
votes

J'ai mon propre environnement de développement, donc je n'ai pas pu le tester sur le même environnement que le vôtre. Mais, je suggère que vous devriez vérifier si npm sous "Program Files" fonctionne bien sur WSL.

#!/bin/sh
(set -o igncr) 2>/dev/null && set -o igncr; # cygwin encoding fix

basedir=`dirname "$0"`

echo $basedir  # Added code

case `uname` in
    *CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac
...

Dans mon cas, une autre erreur se produit lors de l'exécution de la commande ci-dessus.

Error: EINVAL: invalid argument, uv_pipe_open

Si c'est la même chose sur votre environnement, vous pouvez d'abord résoudre ce problème.

Et, à propos du problème du chemin du module, il semble être causé par path; le npm d'origine (sous Program Files) et votre lien symbolique ont un chemin actuel différent.

J'ai modifié le npm d'origine comme ci-dessous:

user@host:~$ /c/Program\ Files/nodejs/npm -v

Si vous exécutez le npm d'origine et votre lien symbolique, $ basedir affichera des résultats différents, et cela causera un problème de chemin de module.

Si vous pouvez résoudre le premier problème (erreur uv_pipe_open), que diriez-vous d'ajouter le répertoire nodejs sur votre chemin au lieu de liens symboliques?


4 commentaires

Et je suggère que vous devriez vérifier que le programme simple network node.js fonctionne bien. Je doute que la version de Windows node.exe ait une implémentation différente pour socket.


Je ne suis pas confronté à l'erreur d'argument non valide, quelle configuration utilisez-vous? L'utilisation du binaire à partir de son emplacement d'origine se termine par le même comportement mais avec un chemin différent (celui de Windows dans WSL) Impossible de trouver le module 'C: \ c \ Program Files \ nodejs \ node_modules \ npm \ bin \ npm-cli.js' Il semble qu'il se passe deux choses ici. Le script npm n'est pas capable d'obtenir le chemin canonique du lien symbolique ET ayant le chemin correct, il doit être transformé en un chemin Windows: / c / foo / bar / baz> c: / foo / bar / baz. Je vais essayer de modifier le script npm pour y parvenir. Peut-être que cela peut être PR à la source du nœud?


J'utilise nvm sur WSL et nvm-windows sur GIt Bash.


Comme je le sais, Node.js pour Windows n'est pas entièrement compatible avec WSL. Et certains modules de nœuds ont une implémentation différente sur Git Bash et WSL. Ainsi, j'ai configuré node.js indépendamment sur WSL et Git Bash.



1
votes

Une solution de contournement? J'ai rencontré la même situation où j'espère partager le même nœud et npm entre WSL et Windows, car je veux les exécuter dans un terminal (WSL) et dans IDEA (Windows) en même temps.

J'ai trouvé que npm ne peut pas être exécuté via des drviers, comme l'utilisation de npm sous C: / , qui a été installé sous F: / , ce qui entraîne une erreur:

# ~/.bash_aliases
function npm() {
  $(realpath --relative-to="$(pwd)" /mnt/f/Program\ Files/nodejs)/npm $@
}
export -f npm

Cependant, nous travaillons toujours dans un pilote, ce qui signifie que nous pouvons installer npm sous le pilote couramment utilisé ( F: / pour moi), et créer un alias pour l'exécuter à l'intérieur du pilote via le chemin relatif:

internal/modules/cjs/loader.js:638
    throw err;
    ^

Error: Cannot find module 'C:\f\Users\aleen\AppData\Roaming\nvm\v10.21.0\node_modules\npm\bin\npm-cli.js'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15)
    at Function.Module._load (internal/modules/cjs/loader.js:562:25)
    at Function.Module.runMain (internal/modules/cjs/loader.js:831:12)
    at startup (internal/bootstrap/node.js:283:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:623:3)


1 commentaires

La question a été créée pour indiquer à Node: github.com/nodejs/node/issues/34165



1
votes

Je n'ai pas pu installer npm dans WSL en utilisant Ubuntu 20.04 LTS sous Windows 10.

Cependant, lorsque j'ai suivi les instructions ici J'ai réussi à le faire fonctionner. Notez que cela dit que c'est pour WSL2, mais les étapes d'installation du nœud sont valides dans un environnement WSL1 (nous sommes le 20 juillet et je ne parviens toujours pas à obtenir WSL dans mon édition de Windows 10, argh!).

Dans en un mot cette solution vous permet d'installer nvm (node ​​version manager) dans votre environnement WSL.

nvm install --lts

Vous pouvez ensuite installer une nouvelle version de node qui est livrée avec npm par défaut, par exemple

sudo apt-get install curl
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.35.3/install.sh | bash


4 commentaires

Ben, après avoir traversé ce processus, npx a-t-il fonctionné pour vous? J'ai utilisé une approche similaire pour installer nvm et node dans Ubuntu, indépendamment de mon installation de nvm et node dans Windows. Le problème est que «quel npx» d'un terminal Ubuntu répond toujours avec «/ mnt / c / Program Files / nodejs / npx». Essayer d'exécuter npx dans Ubuntu entraîne l'erreur, "/ mnt / c / Program Files / nodejs / npx: bin / sh ^ M: mauvais interprète: aucun fichier ou répertoire de ce type". Cependant, exécuter «quel nœud» dans Ubuntu répond par «/ usr / bin / nœud», et tout semble fonctionner lorsque j'exécute des commandes de nœud.


Salut @Lazor. Quand j'ai suivi ces étapes, j'ai pu faire fonctionner nvm (et node), bien que je ne pense pas avoir essayé npx. Cependant, lorsque je faisais ce travail dans WSL, j'ai trouvé que WSL était le coupable de l'ajout du chemin Windows au chemin Linux. Heureusement, WSL a un moyen d'arrêter ce comportement car j'ai publié ici . J'espère que cela t'aides!


Salut Ben, merci pour l'aide. Honnêtement, je ne me souviens pas de ce qui a changé, mais j'ai fait une nouvelle installation d'Ubuntu sur Windows 10 et tout a fonctionné. Après avoir installé nvm puis la dernière version de Node JS, npm et npx ont tous deux fonctionné.


C'est une excellente nouvelle @Lazor. J'ai eu des problèmes similaires, donc je sais ce que vous ressentez (et le soulagement quand vous le faites fonctionner!)