Nvm-windows: Falscher Installationsordner

Liege ich falsch oder hat NVM gerade einen 400 MB Knotenpaket-Cache in mein Roaming-Profil eingefügt?

Nein, das ist ein Fehler in NPM.

Die Standardinstallation verweist auf das lokale Benutzerverzeichnis appdata, nicht auf das Roaming. Obwohl es möglicherweise besser ist, die ausführbare Datei an einem anderen Ort zu speichern, werden alle Knoteninstallationsdateien und npm als Daten für NVM betrachtet (dies ist ein npm-Design). Auch hier sind dies Standardwerte aus einem bestimmten Grund ... Sie können sie ändern, wenn Sie sie nicht mögen.

Ich habe keine Ahnung, woher du 400 MB bekommst. Können Sie nähere Angaben zu Ihrer Umgebung machen?

Beim ersten Punkt besteht der Unterschied vielleicht darin, dass ich es auf einem an die Domäne angeschlossenen Computer installiere und Sie nicht. Aber so oder so ist es immer noch falsch. AppData ist für Benutzereinstellungen, nicht für ausführbare Dateien.

Was den zweiten Punkt angeht, ist es Node selbst, der diesen Fehler macht. Ich werde einen Fehler bei ihnen separat melden.

Dies ist nicht unbedingt "falsch", aber wenn es nachteilige Auswirkungen hat, betrachte ich gerne Ihren Anwendungsfall. Ich hatte nicht die gleiche Erfahrung mit einem an eine Domäne angeschlossenen Computer, daher würden mir Details der Umgebung helfen, Ihren speziellen Anwendungsfall zu verstehen.

Wenn ich beispielsweise weiß, wonach ich suchen muss, kann ich die nächste Version des Installationsprogramms domain-aware machen. Mit anderen Worten, der Standardinstallationsort könnte intelligenter sein.

Hier die Basisempfehlungen:

• Programme gehen in %ProgramFiles% , was normalerweise C:\Program Files .
• Auf einem 64-Bit-Rechner gehen alte x86-Programme in %ProgramFiles(x86)% , was normalerweise C:\Program Files (x86) .
• Maschinenweite Programmdaten, wie Paketcaches, werden in %ProgramData% , was normalerweise C:\ProgramData
• Benutzereinstellungen, die sicher von Computer zu Computer wechseln können, gehen in %APPDATA%
• Benutzereinstellungen, die für einen bestimmten Computer lokal sind (z. B. solche, die Installationspfade enthalten) werden in %LOCALAPPDATA% .

Es ist nicht ungewöhnlich, dass sich ausführbare Dateien in Appdata befinden. Anwendungen, die mit Clickonce installiert werden, tun dies, einem Installationsprogramm von Microsoft. Chrome macht es. Viele Dinge tun es.

@aljones Ein Hauptgrund ist dies – Die Installation von Programmen im Benutzerprofil kann bequem sein, hat jedoch definitiv Sicherheitsfolgen, da jeder Prozess Dinge nach Belieben ändern kann. Beachten Sie, dass ClickOnce im Benutzerprofil _ausführt_, aber auch sicherstellt, dass Assemblys weniger Berechtigungen auf dem System haben.

Während es im Allgemeinen Anwendungsfälle für die Installation von Anwendungen pro Benutzer gibt, ohne dass Administratorrechte erforderlich sind, ist dies ein sehr schlechtes Standardverhalten und Chrome setzt hier einen schlechten Präzedenzfall, imho.

Ich glaube, meine jüngsten Erfahrungen sind für die Diskussion relevant: Ich hatte vor kurzem einen Arbeitsplatzwechsel. Die Pfade für node_packages in meinem Roaming-Profil waren so tief, dass die Wiederherstellung des Roaming-Profils, die mein Computer versucht hat, jedes Mal fehlgeschlagen ist, bis ich den Ordner node_packages entfernt habe. Diese Fehler tauchten in den Windows-Ereignisprotokollen auf. Danach konnte meine neue Workstation endlich mein Roaming-Profil synchronisieren.

Ich stimme zu, dass die Installation zum Roaming zu Problemen führt, wenn Sie in Unternehmen arbeiten, die Ihr Profil sichern, um es in ihren Netzwerken zu verwenden. Mein Computer braucht beispielsweise 30 Minuten zum Herunterfahren und 30 Minuten zum Neustarten; alles aufgrund der npm-Module. Leider, AFAIK, ist dies ein Problem mit NPM selbst.

Als Fortsetzung dazu:

Im Allgemeinen ist es wichtig zu beachten, dass jeder Versionsmanager nur Programme verwaltet. Ich wiederhole einen vorherigen Kommentar.... im Sinne von NVM, das installierte Programm (Knoten) _ist_ die Daten. Wie Sie es verwenden (dh npm-Module) kann zum Footprint beitragen.

@sam3k ist richtig, dass der Footprint definitiv damit zusammenhängt, wie npm gestaltet wurde, und es gibt wirklich nicht viel, was NVM dafür tun sollte, noch kann npm selbst dafür viel tun. Es läuft darauf hinaus, zu wissen, was Sie installieren, und ein Paketmanager jeglicher Art macht es leicht, dies als selbstverständlich zu betrachten. Viele Leute achten nicht auf den Footprint von Modulen, was ein Qualitätsproblem von Code/Umgebung ist, das der Open-Source-Welt innewohnt. Unterm Strich liegt es an der Community, dieses Problem durch disziplinierte Codierungspraktiken zu lösen (eine keineswegs triviale Aufgabe). Ich bin einer von vielen, die dies befürwortet haben (siehe npm braucht einen persönlichen Trainer . Punkt: npm-Management geht über die grundlegende Prämisse der Verwaltung der von Ihnen ausgeführten Knotenversion hinaus.

@aljones und @ygra haben beide gute Punkte. Ich widerspreche ihnen nicht, aber ich möchte alle daran erinnern, dass Administratorrechte eine Notwendigkeit sind, damit Symlinks funktionieren. Dies ist das Kernprinzip der Funktionsweise von NVM für Windows.

@cokobware hat ein meiner Meinung nach häufiges Problem in Unternehmensumgebungen. Die Quintessenz ist, dass npm nicht für eine einfache Portabilität in großem Maßstab entwickelt wurde. Eine Instanz von node+npm ist bereits ziemlich umfangreich, geschweige denn das Hinzufügen mehrerer Versionen. Unabhängig davon, wie sich die Daten/Dateien von Workstation zu Workstation bewegen, es gibt einfach so viele, dass es eine Weile dauern wird. Die Optionen bestehen darin, Windows-Roaming-Profile zu verwenden, alles zu zippen und manuell zu übertragen oder erneut aus einer npm-Registrierung herunterzuladen. Egal, wie Sie es drehen, das Synchronisieren einer Workstation wird nur Zeit brauchen, um alle Bits an die richtige Stelle zu bringen.

Die Zukunft von NVM für Windows (bisher) wird sich wahrscheinlich weiterhin auf den Wechsel der Knotenversion konzentrieren. Ich kann sogar den Projektnamen ändern, um dies widerzuspiegeln. Es wird einem Installationsprogramm weiterhin allgemeine Standardeinstellungen zur Verfügung stellen, aber es bleibt der Organisation/dem Entwickler überlassen, diese Standardeinstellungen in einer für ihre Organisation angemessenen Weise zu überschreiben. Ich sehe das Node-Version-Management als ein deutlich anderes Problem als das npm-Footprint-Management, obwohl ich mit Möglichkeiten experimentiere, wie NVM4W Hooks für ein besseres npm-Management bereitstellen kann.

Bitte folgen Sie dem @Grauenwolf- Vorschlag und diesen Referenzen: Bereitstellungshandbuch , CSIDL und Umgebungsvariablen

• Symlink %USERPROFILE%AppData zu %PROGRAMFILES% oder %PROGRAMFILES(X86)% ist eine schlechte Idee. Problem beim Mehrfachbenutzer (Eigentumsproblem. Anderer Benutzer kann nicht auf den Link zugreifen).
• Programm nvm soll in %PROGRAMFILES% oder %PROGRAMFILES(X86)% gespeichert sein.
• Das nodejses-Repository soll in %PROGRAMDATA% gespeichert werden, da der Geltungsbereich alle Benutzer ist.
• aktiver nodejs-Link soll in %LOCALAPPDATA% gespeichert werden, da der Geltungsbereich pro Benutzer gilt.

NVM kann aufgrund anderer Fehler nicht in %PROGRAMFILES% installiert werden. Wenn Sie es in einen Ordner mit einem Leerzeichen im Namen legen, schlägt der Installationsbefehl fehl.