Nvm-windows: .nvmrc unterstützen

Ich glaube nicht, dass dies ein Weg ist, den ich gehen möchte. Der Hauptgrund ist, dass es einige sehr hässliche Hacks erfordern würde, um die Node-Binärdatei neu zu erstellen / nachzuahmen. Zum Beispiel bedeutet der Aufruf von node index.js dass der gehackte/gefälschte node.exe zuerst die package.json Datei (sofern sie überhaupt existiert) analysieren muss, um die Version zu bestimmen und dann das echte node.exe auszuführen

Einige andere ähnliche Projekte haben versucht, .bat Dateien zu verwenden, um dies zu erreichen. Dieser Ansatz ist fragil und widerspricht dem primären Ziel der Architektur .

Ich glaube auch nicht, dass die Nachfrage dafür groß ist.

Die .nvmrc-Unterstützung ist ein ziemlich wichtiger Aspekt bei der Verwendung von NVM mit einem CI-System. Ich verlinke den package.json-Vorschlag nicht, zumal er die Kompatibilität mit nvm unterbricht, aber würde ein Pull-Request mit Unterstützung für .nvmrc akzeptiert werden?

@gruber76 - Ich werde wahrscheinlich keine PR dazu akzeptieren.

.nvmrc , package.json ... beide erfordern denselben fiesen Hack.

@coreybutler Ich bin mir nicht sicher, ob ich Ihre

Der böse Hack: Symlinks für Windows neu schreiben.

NVM für Windows funktioniert, indem das Symlink-Ziel in das gewünschte Installationsverzeichnis des physischen Knotens geändert wird. Dies ist eine systemweite Änderung.

Angenommen, Sie starten ein Skript, indem Sie Version 0.12.0 in einer .nvmrc Datei angeben, und starten dann ein zweites Skript ohne .nvmrc . Der Symlink würde auf v0.12.0 verweisen (von der ersten Instanziierung). Wenn das zweite Skript etwas anderes erfordert (wie v4.2.6) ohne .nvmrc , schlägt es fehl. Dies führt bei der Verwendung von Symlinks zu Umgebungsinstabilität, da es keine echte Prozessisolation gibt.

Die einzige Möglichkeit, eine Version pro Prozess wirklich zu isolieren, besteht darin, nvm.exe auf die Version umleiten zu lassen, die das Skript anfordert, anstatt dem Betriebssystem zu erlauben, dies zu tun. Ich möchte wirklich nicht etwas nachbauen, was das Betriebssystem bereits für uns tut.

Wenn die Leute wirklich einen prozess-/projektbezogenen Ansatz verwenden möchten, ist die Isolierung der Laufzeitumgebung eine geeignetere Lösung. Ich persönlich verwende dafür Docker.

Verzeihen Sie mir meine Unwissenheit, hier. Mein Hauptanwendungsfall ist die Entwicklung von Knoten-/Webanwendungen mit Bower/Grunt/Gulp usw. mit mehreren Teams. Für mich ist es extrem selten, dass ich mehrere Versionen innerhalb von fünf Minuten hintereinander laufen lassen würde. Für diesen Anwendungsfall geben meine Teams mit der .nvmrc-Datei an, welcher Knoten ausgeführt werden soll.

Ich habe Probleme in der von Ihnen beschriebenen Situation (Skript A im Vergleich zu Skript B) zu sehen, dass die Unterstützung von .nvmrc mühsamer wäre, als wenn Skript A (oder ein Benutzer von Skript A) nvm aufruft, um die Version zu setzen und dann zu vergessen es vor dem Ausführen von Skript B. Aber ich vermute, dass es einige allgemeine Anwendungsfälle für nvm gibt, die viel härter sind als meine. Möglicherweise zum Beispiel, wenn meine CI-Server stärker ausgelastet sind.

Ich habe einen Hackey-Workaround, den ich jedem anbieten kann, der ihn braucht. Folgendes in einem vorab ausgeführten bat-Skript:

set /p nodev=<.nvmrc
nvm install %nodev%
nvm use %nodev%

Warum fügen Sie nicht den nvm-Befehl ein, um die erforderliche Version in einem npm-Skript festzulegen?

Steve Lee
Von meinem Mobilgerät gesendet Bitte entschuldigen Sie Tippfehler
Am 3. März 2016 um 16:50 Uhr schrieb "gruber76" [email protected] :

Verzeihen Sie mir meine Unwissenheit, hier. Mein primärer Anwendungsfall ist die Entwicklung
Knoten-/Webanwendungen mit Bower/Grunt/Gulp usw. mit mehreren Teams. Zum
Bei mir ist es extrem selten, dass mehrere Versionen in mir laufen
fünf Minuten voneinander. Für diesen Anwendungsfall ist die .nvmrc-Datei wie mein
Teams geben an, was Node tun soll.

Ich habe Probleme, die von Ihnen beschriebene Situation zu sehen (Skript A versus
Skript B) wie mühsamer wäre, .nvmrc zu unterstützen, als zu haben
Skript A (oder ein Benutzer von Skript A) ruft nvm auf, um die Version einzustellen und dann
vergessen, es einzustellen, bevor Skript B ausgeführt wird. Aber ich vermute, es gibt
einige gängige Anwendungsfälle für nvm, die viel härter sind als meine.
Möglicherweise zum Beispiel, wenn meine CI-Server stärker ausgelastet sind.

Ich habe einen Hackey-Workaround, den ich jedem anbieten kann, der ihn braucht. Die
Folgendes in einem vorab ausgeführten bat-Skript:

set /p nodev=<.nvmrc
nvm installieren %nodev%
nvm verwenden %nodev%

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/coreybutler/nvm-windows/issues/128#issuecomment -191852401
.

Die Unterstützung der Datei .nvmrc wäre wirklich hilfreich. Wir haben viele Projekte, und sie führen nicht alle dieselbe Version von node aus. Die Datei .nvmrc befindet sich im Stammverzeichnis jedes Repositorys, um sicherzustellen, dass die richtige Knotenversion für ein bestimmtes Projekt verwendet wird.

Als Randnotiz ist es auch irgendwie ärgerlich, dass auf nvm install nvm use folgen muss. Ich bin gespannt, warum der zweite Schritt nach einer Installation erforderlich ist. Ich kann sehen, dass Installieren und Verwenden unterschiedliche Dinge sind, aber ich frage mich, ob es jemals einen Anwendungsfall gibt, bei dem jemand herunterlädt und installiert, aber nicht verwendet.

Unser Workaround dafür besteht darin, dass wir eine Datei namens install-node.js , die im Stammverzeichnis jedes Projekts gespeichert ist. Immer wenn wir zu einem Projekt wechseln, führen wir node install-node über die Befehlszeile aus. Der Inhalt der Datei install-node.js lautet wie folgt:

var childProcess = require('child_process')
var fs = require('fs')

var nodeVersion = fs.readFileSync('.nvmrc', 'utf8').trim()

var command = "nvm install " + nodeVersion + " && nvm use " + nodeVersion
console.log('executing command: ' + command)
childProcess.exec(command, function(error, stdout, stderr) {
  if (stdout) console.log(stdout.toString())
  if (stderr) console.error(stderr.toString())
  if (error) console.error(error)
})

@josh-egan-ps - Die Trennung zwischen install und use diente hauptsächlich der Massenumgebungskonfiguration. Ich werde oft mehrere Versionen von Node installieren, bevor ich zwischen ihnen wechsele. Jedoch; Es scheint völlig vernünftig, ein Flag wie nvm install -u 5.9.1 zu haben, das installiert und automatisch verwendet wird... oder automatisch die Version verwenden und ein Flag haben, um es _nicht_ zu verwenden. Ich werde auf jeden Fall in Betracht ziehen, dies hinzuzufügen.

Für alle - Wenn Sie wirklich auf Projektbasis wechseln müssen, sollten Sie nvm use x.x.x && node index.js in den npm-Startskriptabschnitt Ihrer package.json einfügen. Eine gängige Best Practice besteht darin, immer npm start zu verwenden, um eine Knoten-App zu starten.

Für alle - Wenn Sie wirklich projektbezogen wechseln müssen, sollten Sie in Erwägung ziehen, nvm use xxx && node index.js in den Abschnitt npm start script Ihrer package.json zu setzen. Eine gängige Best Practice besteht darin, immer npm start zu verwenden, um eine Knoten-App zu starten.

Das könnte tatsächlich zu spät sein, falls npm _build_-Skripte während der Installation verwendet werden, die von der Node / npm-Version abhängen. Oder andere Tools wie grunt etc laufen explizit Sie könnten während der Installation mit der falschen Version von node/npm fehlschlagen. oder verwenden Sie die falsche Version, die andere Probleme verursacht. Übrigens gehe ich davon aus, dass _alles_ lokal installiert ist (dh nicht -g), damit Versionsabhängigkeiten nie ein Problem sind.

Daher ist es eine gute Praxis, npm install zu verwenden, um alles einzurichten. Sie können dann einen Vorinstallationsschritt hinzufügen, um die nvm-Verwendung zu verwenden. zB hinzufügen

    "preinstall": "nvm use x.x.x",

Das sollte in Ordnung sein, auch wenn die ursprüngliche npm-Version im übergeordneten Prozess ausgeführt wird. Der Installationsschritt startet eine neue Shell, sodass alle Aktionen den neuen Knoten und npm aufnehmen sollten.

Vielleicht möchten Sie sogar einen Pre-Start-Schritt als Installationen hinzufügen.

@SteveALee - ja, du hast Recht, mein früherer Vorschlag würde nicht funktionieren. Für einen zuverlässigen Start wäre es zu spät.

@coreybutler Am Ende habe ich mich dafür entschieden

"preinstall":"nvm use 4.4.1 || echo nvm not found: check node version && pause",

Vielleicht wäre eine Option nvm use -i x.x.x gut? Das heißt, installieren, wenn nicht bereits vorhanden?

Ich möchte vorschlagen, zumindest einen Teil davon umzusetzen:

Unter Linux / Mac kann ich in einem Ordner mit einer .nvmrc Datei nvm use ausführen, ohne eine konkrete Version anzugeben, und die installierte Version, die dem Inhalt von .nvmrc erhält aktiviert. Wenn die Datei 8 sagt, wird die neueste installierte Version von Node 8 installiert.

Ich kombiniere dies auf meinen Systemen mit einem Skript, das cd überlädt, damit ich cd in ein Verzeichnis eingeben kann und die richtige Version des Knotens aktiviert wird, mit diesem Skript in .bashrc :

# Support .nvmrc
load-nvmrc() {
  if [[ -f .nvmrc && -r .nvmrc ]]; then
    nvm use
  elif [[ $(nvm version) != $(nvm version default)  ]]; then
    echo "Reverting to nvm default version"
    nvm use default
  fi
}
# Override `cd` to auto-load correct version of Node on enterting directory.
cd() { builtin cd "$@"; 'load-nvmrc'; }

Dies könnte auch unter Windows problemlos funktionieren, wenn nvm diese Dateien respektiert.

Eine .nvmrc wird standardmäßig nicht implementiert. Jedoch; die Roadmap enthält einen Plan für Hook-Unterstützung (https://github.com/coreybutler/nvm-windows/issues/190). Ein pre-use Skript könnte verwendet werden, um die Version an jede gewünschte Datei anzupassen (einschließlich package.json, .nvmrc oder alles andere, was Sie wählen).

Da dieses Problem fast tot zu sein scheint, habe ich ein Powershell-Skript zur Umgehung, das die Funktionalität von "nvm use" und "nvm install" nachahmen sollte, wenn die .nvmrc-Datei eine einstellige Knotenversion enthält.

nvm install (Get-Content .nvmrc) würde gut funktionieren, aber nvm use (Get-Content .nvmrc) wird nicht funktionieren (denn wenn eine einstellige Version an die Installation übergeben wird, wird die neueste Revision dieser Knotenversion installiert, aber nvm use mit eine einzelne Ziffer hängt '.0.0' an, anstatt die neueste zu erhalten.

@coreybutler Wenn Sie den Befehl "use" in nvm.go aktualisiert haben, um denselben Code wie install , würde dieser Fix unnötig werden (dh):
if len(version) == 1 { version = findLatestSubVersion(version) } else { version = cleanVersion(version) }

Das folgende Skript verwendet "nvm list available" und filtert die Liste nach der höchsten LTS-Version, die der Version der .nvmrc-Datei entspricht, und "nvm use". Wenn es nicht installiert ist, 'nvm install' es dann 'nvm use'.
((nvm use (nvm list available | Where-Object -FilterScript { $_ -like ('* ' + (Get-Content .nvmrc)) + '.*'})[0].split('|')[2].trim()) -like '*not installed*') -and (nvm install (nvm list available | Where-Object -FilterScript { $_ -like ('* ' + (Get-Content .nvmrc) + '.*') })[0].split('|')[2]) -and (nvm use (nvm list available | Where-Object -FilterScript { $_ -like ('* ' + (Get-Content .nvmrc) + '.*') })[0].split('|')[2].trim())

Ich möchte nur die Unterstützung von nvm anfordern, um aus einer .nvmrc-Datei zu lesen. Es würde wirklich meine Erfahrung in der Knotenentwicklung zwischen Mac und Windows machen, um nahtlos zu sein.

Ist das geschlossen, weil es behoben wurde oder wird es nicht geändert?

Gibt es eine andere Windows-kompatible Version von nvm , die dieselbe API wie die *nix-Versionen verwendet?