Visual Studio Code zur Verwendung der von NVM angegebenen Knotenversion

78

Kann VS Code die von NVM angegebene Knotenversion verwenden?

Ich habe 6.9.2 lokal installiert. Auch nach dem Wechsel zu einer anderen Version vom OS X-Terminal (nicht vom VS Code-Terminal) und dem Neustart von VS Code wird VS Code weiterhin mit 6.9.2 angezeigt.

OS X-Terminal

MacBook-Pro-3:~ mac$ node -v
v7.8.0

VS Code Terminal

MacBook-Pro-3:QB-Invoice-API mac$ node -v
v6.9.2
Aseem Gautam
quelle
Verwandte (und mögliche Vervielfältigung): stackoverflow.com/questions/24585261/…
Gyuri

Antworten:

86

Wechseln Sie in VS Code zu Ihrer Datei launch.json und fügen Sie das Attribut runtimeVersion in den Konfigurationen hinzu, wie unten gezeigt. (In diesem Beispiel wird davon ausgegangen, dass 4.8.7 bereits mit nvm installiert ist.)

{
"version": "<some-version>",
"configurations": [
    {
        "type": "node",
        "runtimeVersion": "4.8.7", // If i need to run node 4.8.7
        "request": "launch",
        "name": "Launch",
        "program": "${workspaceFolder}/sample.js"
    }
]}
Sm Srikanth
quelle
4
Ich wollte fragen, woher Code weiß, wo diese Version zu finden ist, aber anscheinend wurde diese Option speziell für nvm hinzugefügt. code.visualstudio.com/docs/nodejs/…
Brian Witt
2
Wo ist die launch.jsonDatei?
Petrus Theron
@PetrusTheron Wenn Sie noch keinen haben, müssen Sie einen erstellen. Hier finden Sie Anweisungen: code.visualstudio.com/docs/editor/debugging#_run-view
Joel Glovier
60

Die Lösung besteht darin, einen Alias ​​festzulegen default. Im OS-Terminal ausführen -

nvm alias default 7.8.0

Öffnen vscode, jetzt laufenden node -vErträge7.8.0

Es scheint, dass vscode diesen (Alias-Standard-) Wert verwendet und nicht die Knotenversion, die von festgelegt wird nvm use X.X.X

Starten Sie den VS-Code neu, damit die Änderungen übernommen werden.

Update (12/04/2018) - Diese Lösung funktioniert möglicherweise nicht für alle. Weitere Antworten finden Sie in den Antworten unten.

Aseem Gautam
quelle
1
Dies hat auch bei mir funktioniert, aber es sollte eine einfache Möglichkeit geben, den Pfad zum Knoten global für VSCode anzugeben.
jr.
3
Das hat nicht funktioniert. Nach dem Aliasing muss ich nvm use defaultjedes Mal verwenden, wenn ich ein neues Terminal
benutze
Hat auch bei mir nicht funktioniert. Auch nicht mit nvm use default.
Matt Sanchez
2
Ich musste meine von Brew installierte Version des Knotens entfernen, bevor dies funktionierte.
Samlandfried
2
Ich verwende VS Code mit WSL. Nach dem Festlegen des Standardalias muss VS Code neu gestartet werden, damit die Änderung übernommen wird.
John Mills
51

füge runtimeExecutabledeinem .vscode/launch.jsonso hinzu

{
  "type": "node",
  "request": "launch",
  "name": "App",
  "program": "${workspaceRoot}/index.js",
  "runtimeExecutable": "${env:HOME}/.nvm/versions/node/v6.9.2/bin/node"
}
Alongkorn Chetasumon
quelle
@Kiong Sie können eine neue Datei erstellen und den obigen Inhalt darauf kopieren
Alongkorn Chetasumon
erstelle ich die launch.jsonDatei im Stammverzeichnis meines Projekts?
Kiong
1
@Kiong Erstelle das Verzeichnis ".vscode" im Stammverzeichnis deines Projekts und erstelle darin "launch.json".
Alongkorn Chetasumon
39

Ich hatte das gleiche Problem, dass ich meine durch nvm angegebene Knotenversion in meiner OS X-Umgebung nicht nur mit VSCode, sondern auch mit Atom Editor (unter Verwendung des platformio-ide-terminal-Pakets zur Verwaltung des darin integrierten Terminals) nicht beibehalten konnte. Keiner der Vorschläge in den vorherigen Antworten hat für mich funktioniert, außer dass ich nicht den Debugger, sondern Schluck und Grunzen für bestimmte Aufgaben verwendet habe. Anscheinend versteht sich nvm zumindest in diesen Editoren nicht mit den integrierten Terminals oder Sub-Shells, da beim Laden die Umgebungsvariable $ PATH intern geändert wird und gemäß einem Kommentar eines Mitwirkenden dieses Pakets in dieser Ausgabe Folgendes ausgeführt wird Hier kann NVM nicht in die verschachtelte Shell # 1652 geladen werden :

" @charsleysa Ich weiß, warum nvm diesen Fehler auslöst. In Ihrer Subshell wurde der / usr / local / bin: / usr / bin: / bin: / usr / sbin: / sbin-Teil Ihres Pfads vom Ende verschoben des Pfades zum Start.

  • Wenn nvm dann gestartet wird, ruft es nvm_change_path auf (mein Beitrag hat es von nvm_prepend_path geändert), wodurch der nvm-relevante Teil des vorhandenen Pfads geändert wird.
  • Nvm überprüft dann das aktuelle npm-Präfix, indem es npm fragt, was es ist. Da / usr / local / bin / npm jetzt Vorrang hat, wird / usr / local / bin gemeldet.
  • Nvm prüft dann, ob sich das von npm gemeldete aktuelle Präfix im Verzeichnisbaum der aktuellen nvm-Knotenversion befindet (in diesem Stadium wird das Installationsverzeichnis der Knotenversion aufgelöst, in die Ihr Standard-nvm-Alias ​​aufgelöst wird).
  • Das Präfix ist nicht Teil dieses Baums, daher deaktiviert es sich selbst (ruft dabei nvm_strip_path auf, weshalb der PATH Ihrer Subshell keinen nvm-bezogenen Pfad enthält) und wird mit dem Fehler, den Sie erhalten, behoben. Das / etc / profile (oder / etc / zprofile) von macOS ruft / usr / libexec / path_helper auf, wodurch das PATH-Umschalten ausgeführt wird.

In der übergeordneten Shell enthält der PATH noch kein nvm-Verzeichnis. Wenn nvm ausgeführt wird, wird sein Verzeichnis dem Pfad vorangestellt. Aber in der Subshell wurde PATH von macOS neu konfiguriert, um alle Nicht-System-Verzeichnisse am Ende zu platzieren, und wir haben das Problem. "

Beim Starten eines integrierten Terminals wurde immer folgende Meldung angezeigt:

nvm ist nicht kompatibel mit der Option "Präfix" der npm-Konfiguration: Derzeit auf "/ usr / local" eingestellt. Ausführen npm config delete prefixoder nvm use --delete-prefix vx.x.x --silentdeaktivieren.

Was ich getan habe, um dies in meinem Fall zu lösen, war der "Workaround" -Teil desselben gemeldeten Problems, der im Wesentlichen der folgende ist:

  • Setzen Sie den Pfad zurück, indem Sie die folgende Zeile in mein ~ / .bash_profile ganz oben vor allem anderen einfügen: PATH = "/ usr / local / bin: $ (getconf PATH)"

Und danach keine Warnungen mehr, wenn ich ein integriertes Terminal auf beiden Editoren starte und mit nvm interagieren kann, um einfach und problemlos zwischen beliebigen Knotenversionen zu wechseln.

Hier ist es eine andere Alternative für den Fall, dass diese nicht so viel hilft.

Charlyboy
quelle
2
Dies sollte die akzeptierte Antwort sein. Ich habe zuvor die runtimeVersionDatei in launch.json festgelegt, aber dadurch wird nur die Knotenversion für eine bestimmte Aufgabe festgelegt. Dies funktioniert in der gesamten integrierten Terminalinstanz. Vielen Dank! NB. Ich musste die PATH- .zshrc
Variable einstellen,
Nachdem ich den bereitgestellten alternativen Link gelesen hatte - was darauf hindeutete, dass das Problem bei nvm lag und wie Subshells behandelt wurden -, aktualisierte ich nvm auf v0.34.0 und es funktioniert ohne die Problemumgehung für den Rücksetzpfad.
Timiscoding
22

Ich hatte das gleiche Problem, aber die obigen Antworten haben nicht geholfen.

Anscheinend sind die Standardeinstellungen shellArgsfür osx bashwährend der Verwendung festgelegt zsh. Ich habe das Problem gelöst, indem ich shellArgsin meinen Benutzereinstellungen ein leeres Array festgelegt habe:

"terminal.integrated.shellArgs.osx": []

Skeevs
quelle
2
Wenn which nodees sich von cli von vscode unterscheidet, ist dies Ihre Lösung! 🚀
Manelescuer
17

Ich verwende oh-my-zsh und es wurde auch nicht die von nvm angegebene Knotenversion verwendet. Ich habe mehrere hier veröffentlichte Vorschläge ausprobiert, aber die einzige Möglichkeit, dieses Problem zu beheben, bestand darin, die folgende Zeile oben in hinzuzufügen~/.zshrc

PATH="/usr/local/bin:$(getconf PATH)"
BlueTabasco
quelle
1
Ich benutze auch oh-my-zsh und nur diese Lösung hat bei mir funktioniert. ich danke dir sehr. Jetzt muss ich die Knotenversion nicht jedes Mal ändern, wenn ich VS Code öffne.
Rameshwor Maharjan
Dies löste auch mein Problem mit vs Code. Vielen Dank!
Imcc
Ich hatte das gleiche Problem, da macos auf zsh umgestellt hat, nachdem nvm (und das vscode-Plugin) bereits installiert waren und funktionierten. Übrigens musste ich VSCode neu starten (nicht nur neu laden), um die Umgebung zu aktualisieren.
tutuDajuju
Dies war der einzige, der für mich arbeitete. Vielen Dank!
Rafael Rozon
12

Eine alternative Lösung, die ich gefunden habe, besteht darin, einfach Code aus der Shell zu starten, nachdem Sie Ihren Knoten mit nvm ausgewählt haben.

Sie müssen zuerst die Befehlspalette öffnen und "Code in Pfad installieren" auswählen.

Geben Sie hier die Bildbeschreibung ein

Starten Sie dann ein Terminal und wählen Sie Ihren Knoten über nvm aus und starten Sie dann "Code".

Geben Sie hier die Bildbeschreibung ein

jr.
quelle
Ich habe dies verwendet und festgestellt, dass, wenn Sie in die VScode-Symbolleiste gehen und die Seite "Über" aufrufen, immer noch die alte Version angezeigt wird. Wenn ich jedoch die Befehlszeile verwende, wird mir mitgeteilt, dass sie auf die zeigt aktualisierte Version, so funktioniert es irgendwie.
Harvey Lin
Dazu muss VSCode geschlossen und über die Befehlszeile neu gestartet werden, damit es effektiv funktioniert.
Wallace Sidhrée
8

Einige der Antworten sind korrekt und positiv bewertet, aber etwas unvollständig. Dieses Verfahren hat bei mir funktioniert:

  1. Öffnen Sie das Terminalfenster in VS Code und führen Sie es aus node -v. Sie werden zum Beispiel bekommen v10.12.0.
  2. Öffnen Sie ein Terminalfenster außerhalb von VS Code. Ändern Sie Ihre Knotenversion mit nvm (dh nvm use v12.14.0).
  3. Cmd+ Shift+ pUnd wählen Sie Einstellungen> Einstellungen öffnen (JSON)
  4. Fügen Sie "terminal.integrated.shellArgs.osx": []Ihrer Benutzerkonfiguration hinzu
  5. Cmd+ Shift+ pund wählen Sie Shell-Befehl: Installieren Sie den Befehl 'Code' in PATH
  6. Schließen Sie den VS-Code .
  7. Öffnen Sie ein Terminalfenster und führen Sie es aus code. Dies öffnet VS - Code mit einem neuen und aktualisierten bash/ zshSitzung.
  8. Öffnen Sie das Terminalfenster in VS Code und führen Sie es aus node -v. Du wirst bekommen v12.14.0.

Bonus: Wenn Sie immer eine bestimmte Knotenversion auf dem VS Code -Terminal erhaltenmöchten, legen Sie diese als Standard fest, indem Sie ein Terminalfenster außerhalb von VS Code öffnenund Folgendes ausführen:

nvm alias default v12.14.0
Wallace Sidhrée
quelle
4

Ich habe alle vorgeschlagenen Lösungen ausprobiert, aber nichts hat funktioniert.

/ usr / local / bin / node zeigte irgendwo hin. Ich habe einen Symlink zu einem bestimmten NVM-Knotenordner erstellt und das hat das Problem für mich gelöst:

ln -s /Users/mad/.nvm/versions/node/v11.1.0/bin/node /usr/local/bin/node
madflanderz
quelle
4

Besonders mit der Shell hatte ich keine Probleme, aber Sie können:

  • Überprüfen Sie, ob Ihre Shell ordnungsgemäß konfiguriert oder geändert wurde (möglicherweise verwenden Sie unterschiedliche Shells für vscode oder Ihr Terminal).
  • Überprüfen Sie Ihre Umgebung und verwenden Sie die, wenn sie nicht richtig eingestellt ist terminal.integrated.env.<platform>

Ich hatte Probleme mit vscode selbst und keine Lösung konnte mir helfen. Also habe ich das folgende Startskript nicht mehr verwendet.

    {
        "type": "node",
        "request": "launch",
        "name": "Launch Program",
        "program": "${workspaceFolder}/server.js",
        "runtimeExecutable": "/bin/bash",
        "runtimeArgs": ["-c", ". ~/.nvm/nvm.sh;nvm run default \"$@\"", "dummy"]
    },

Dies setzt voraus, dass Sie es für Bash konfiguriert haben (andernfalls ändern Sie es in Ihre Shell) und Sie möchten die defaultvon nvm konfigurierte Knotenversion verwenden (Sie können sie auch ändern).

Hinweis : Der Parameter "Dummy" ist erforderlich, damit die restlichen Parameter ordnungsgemäß analysiert werden.

Eine längere Erklärung von "Dummy": Shell-Skripte verwenden Positionsparameter, wobei der erste der Skriptspeicherort selbst ist (adressiert von $0). Wenn Sie das -cFlag verwenden, wird das Skript an Ort und Stelle gelesen und es wird kein $0Satz festgelegt. vscode übergibt einige Argumente, z. B. die Position des Knotenstart-Skripts, die falsch interpretiert wird. "Dummy" verschiebt also alle Parameter um eine Stelle. Es kann einfach alles sein, aber es muss da sein.

estani
quelle
4

Ich hatte das gleiche Problem und fand eine seltsame Problemumgehung, die in Zukunft für andere hilfreich sein könnte.

Wenn ich nicht einstelle eslint.runtime, läuft auf meinem System ein Knoten v10.11.0für den Eslint-Server, während ich wollte, dass er ausgeführt wird, v12.13.0den ich installiert und über festgelegt habe nvm.

Ich fand heraus, dass die v10-Version des Knotens brewbasierend auf der Antwort von @ franziga installiert wurde , aber meine gewünschte Version des Knotens wurde von installiert nvm. Also habe ich v10.11.0via Brew deinstalliert und VS Code geschlossen / wieder geöffnet. Seltsamerweise berichtete eslint immer noch, dass es mit v10 gestartet wurde.

Ich habe versucht, eine Shell ohne Änderungen an meinem PATHin Startskripten auszuführen, und die Version des Knotens wurde erwartungsgemäß immer noch korrekt auf Version 12 verwiesen, aber VS-Code startet weiterhin Version 10 für eslint.

Ich bin nicht sicher, wie ich den Pfad der ausführbaren Datei überprüfen soll, die von eslint ausgeführt wird, und wenn ich ein integriertes Terminal öffne, funktioniert alles einwandfrei mit der erwarteten Version von node (v12).

Lösung (für mich):

Ich fand , dass , wenn ich gesetzt "eslint.runtime": "node"in , settings.jsondass es jetzt wird verwenden , was Version nodeaktiv war , als ich vscode mit öffnete code .am Terminal. Nur "node"- kein Weg.

Monkpit
quelle
1
Diese Lösung hat mir am besten geholfen. Ich musste auch keinen Code vom Terminal aus öffnen.
Matt Scheurich
2

Ich habe das gleiche Problem und habe festgestellt, dass ich nodevon brewund installiert habe nvm. Ich habe deinstalliert von nodeinstalliert brewund die Versionen auf Terminal- und Visual Studio-Code sind jetzt gleich.

franziga
quelle
2

Sie müssen Ihre Standardknotenversion nicht ändern. Im folgenden Beispiel wird davon ausgegangen, dass Knoten 6 Ihre Standardversion ist und VSCode auf Version 7 des Knotens verweisen soll:

# open a terminal instance
nvm use 7
code . # or project folder instead of "."
# when VSCode start, you may use ctrl+` to open the integrated terminal
# then check the node version in the integrated terminal
node -v # should print 7
Mateja Petrovic
quelle
0

Ich habe nicht die gesamte Lösung ausprobiert, aber für mich hat das Aktualisieren von nvm einfach funktioniert.

Folgen Sie einfach der Installation hier und stellen Sie sicher, dass Sie bash_profileaktualisiert sind.

michelepatrassi
quelle
0

Ihr nvm ist also gut konfiguriert, aber andere Versionen des Knotens STILL übernehmen weiterhin?

Entfernen Sie alle Nicht-NVM-Versionen des Knotens:

  1. brew uninstall --force node (Garn ist ohne Systemknoten in Ordnung)
  2. Andere Version von pkg oder einer anderen Nicht-NVM-Methode installiert
  3. Erneut anmelden. Jetzt kann nichts mehr mit nvm um den Pfad kämpfen, egal wie die Shell gestartet wird.

Hinweis: Verwenden Sie zum Installieren / Aufrüsten von Garn brew install yarn --without-node

Stepan
quelle
Für die Liebe von Pete besteht keine Notwendigkeit, brewKnoten zu installieren. Es hat ein natives Installationsprogramm! nodejs.org/en/download
jnovack
@jnovack Meine Antwort bezieht sich auf die Deinstallation der von Brew installierten Version des Knotens. Bitte lesen Sie es noch einmal. Darüber hinaus ist die Verwendung brewzum Installieren von Knoten für Benutzer, die dies nicht benötigen, recht gut nvmund bietet Vorteile gegenüber dem nativen Installationsprogramm.
Stepan
0

Keine der anderen Lösungen hat bei mir funktioniert.

Also rannte ich nvm alias default nodeund das reparierte es für mich.

coinGuyBri
quelle
Achtung: nvm alias default nodeLegt die aktuellste Version des installierten Knotens fest, nicht eine bestimmte Version, die Sie möchten.
jnovack