Visual Studio Code zur Verwendung der von NVM angegebenen Knotenversion

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

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"
    }
]}

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.

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"
}

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.

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": []

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)"

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.

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

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

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

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.

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.

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.

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

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.

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

Keine der anderen Lösungen hat bei mir funktioniert.

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