Nvm-windows: Dossier d'installation incorrect

Est-ce que je me trompe ou NVM vient-il de mettre un cache de paquet de nœuds de 400 Mo dans mon profil itinérant ?

Non, c'est un bug dans NPM.

L'installation par défaut pointe vers le répertoire appdata de l'utilisateur local, pas l'itinérance. Bien qu'il soit préférable d'avoir l'exécutable dans un emplacement différent, tous les fichiers d'installation de nœud et npm sont considérés comme des données pour NVM (il s'agit d'une conception npm). Encore une fois, ce sont des valeurs par défaut pour une raison... vous pouvez les changer si vous ne les aimez pas.

Je n'ai aucune idée d'où vous obtenez 400 Mo. Pouvez-vous fournir plus de détails sur votre environnement?

Sur le premier point, la différence est peut-être que je l'installe sur un ordinateur attaché au domaine et que vous ne l'êtes pas. Mais de toute façon, c'est toujours faux. AppData est destiné aux paramètres utilisateur, pas aux exécutables.

Quant au deuxième point, c'est Node lui-même qui fait cette erreur. Je vais déposer un bogue avec eux séparément.

Ce n'est pas nécessairement « faux », mais si cela a des effets indésirables, je serai heureux de considérer votre cas d'utilisation. Je n'ai pas eu la même expérience avec un ordinateur attaché à un domaine, donc encore une fois, les détails de l'environnement m'aideraient à comprendre votre cas d'utilisation spécifique.

Par exemple, si je sais quoi rechercher, je peux rendre la prochaine version du programme d'installation compatible avec le domaine. En d'autres termes, l'emplacement d'installation par défaut pourrait être plus intelligent.

Voici les recommandations de base :

• Les programmes vont dans %ProgramFiles% , qui est généralement C:\Program Files .
• Sur une machine 64 bits, les anciens programmes x86 vont dans %ProgramFiles(x86)% , qui est généralement C:\Program Files (x86) .
• Les données de programme à l'échelle de la machine, comme les caches de packages, vont dans %ProgramData% , qui est normalement C:\ProgramData
• Les paramètres utilisateur qui peuvent se déplacer en toute sécurité d'une machine à l'autre vont dans %APPDATA%
• Les paramètres utilisateur qui sont locaux pour une machine donnée (par exemple, ceux qui contiennent des chemins d'installation) vont dans %LOCALAPPDATA% .

Il n'est pas rare que les exécutables soient dans appdata. Les applications installées à l'aide de clickonce le font, qui est un programme d'installation créé par Microsoft. Chrome le fait. Beaucoup de choses le font.

@aljones L'une des principales raisons est la suivante : l'installation de programmes dans le profil utilisateur peut être pratique, mais cela a certainement des conséquences sur la sécurité dans la mesure où tout processus peut modifier des éléments à sa guise. Notez que ClickOnce _fait_ l'installation dans le profil utilisateur mais garantit également que les assemblys ont moins de privilèges sur le système.

Bien qu'il existe en général des cas d'utilisation pour installer des applications par utilisateur sans avoir besoin de privilèges administratifs, il s'agit d'un comportement par défaut très médiocre et Chrome crée un mauvais précédent ici, à mon humble avis.

Je pense que mon expérience très récente est pertinente pour la discussion : j'ai récemment eu un changement de poste de travail. Les chemins des node_packages dans mon profil itinérant étaient si profonds que la restauration du profil itinérant que ma machine essayait de faire échouerait à chaque fois jusqu'à ce que je supprime le dossier node_packages. Ces erreurs sont apparues dans les journaux d'événements Windows. Après cela, mon nouveau poste de travail a enfin pu synchroniser mon profil d'itinérance.

Je conviens que l'installation en itinérance pose des problèmes lorsque vous travaillez sur des entreprises qui sauvegardent votre profil pour être utilisé dans leurs réseaux. Par exemple, il faut 30 minutes à mon ordinateur pour s'arrêter et 30 minutes pour redémarrer ; tout cela grâce aux modules npm. Malheureusement, autant que je sache, c'est un problème avec le NPM lui-même.

Pour faire suite à ceci :

En général, il est important de noter que tout gestionnaire de versions ne gère que des programmes. Je réitère un commentaire précédent.... dans le sens de NVM, le programme installé (nœud) _est_ les données. La façon dont vous l'utilisez (c'est-à-dire les modules npm) peut contribuer à l'empreinte.

@sam3k a raison de dire que l'empreinte est certainement liée à la façon dont npm a été conçu, et il n'y a vraiment pas grand-chose que NVM _devrait_ faire pour cela, ni n'en lui-même peut faire grand-chose pour cela. Cela se résume à savoir ce que vous installez, et un gestionnaire de paquets de tout type permet de tenir cela pour acquis. Beaucoup de gens ne font pas attention à l'empreinte des modules, qui est un problème de qualité de code/environnement inhérent au monde open source. En fin de compte, c'est à la communauté de résoudre ce problème grâce à des pratiques de codage disciplinées (une tâche loin d'être triviale). Je fais partie de ceux qui ont préconisé cela (voir npm a besoin d'un entraîneur personnel . Point : la gestion de npm va au-delà du principe de base de la gestion de la version du nœud que vous exécutez.

@aljones et @ygra ont tous les deux de bons points. Je ne suis pas en désaccord avec eux, mais je tiens à rappeler à tout le monde que les privilèges administratifs sont une nécessité pour que les liens symboliques fonctionnent. C'est le principe de base du fonctionnement de NVM pour Windows.

@cokobware a ce que je pense être un problème courant dans les environnements d'entreprise. L'essentiel est que npm n'a pas été conçu pour une portabilité facile à grande échelle. Une instance de node+npm est déjà assez lourde, sans parler de l'ajout de plusieurs versions. Quelle que soit la façon dont les données/fichiers se déplacent d'un poste de travail à l'autre, il y en a tellement que cela va prendre un certain temps. Les options consistent à utiliser les profils itinérants Windows, à tout compresser et à transférer manuellement, ou à télécharger à nouveau à partir d'un registre npm. Peu importe comment vous le faites tourner, la synchronisation d'un poste de travail va juste prendre du temps pour mettre tous les bits au bon endroit.

L'avenir de NVM pour Windows (à partir de maintenant) restera probablement axé sur le changement de version de nœud. Je peux même changer le nom du projet pour refléter cela. Il continuera à fournir un programme d'installation avec des valeurs par défaut communes, mais il appartiendra toujours à l'organisation/au développeur de remplacer ces valeurs par défaut d'une manière appropriée pour leur organisation. Je considère la gestion de la version des nœuds comme un problème nettement différent de la gestion de l'empreinte npm, bien que j'expérimente des moyens par lesquels NVM4W peut fournir des crochets pour une meilleure gestion npm.

Veuillez suivre la suggestion de @Grauenwolf et ces références : guide de déploiement , CSIDL et variables d'environnement

• Le lien symbolique %USERPROFILE%AppData vers %PROGRAMFILES% ou %PROGRAMFILES(X86)% est une mauvaise idée. Problème dans l'utilisateur multiple (problème de propriété. Un autre utilisateur ne peut pas accéder au lien).
• Le programme nvm est supposé être stocké dans %PROGRAMFILES% ou %PROGRAMFILES(X86)%.
• Référentiel nodejses censé être stocké dans %PROGRAMDATA% puisque la portée est tous les utilisateurs.
• lien nodejs actif censé être stocké dans %LOCALAPPDATA% puisque la portée est par utilisateur.

NVM ne peut pas être installé dans %PROGRAMFILES% à cause d'autres bogues. Si vous le placez dans un dossier dont le nom contient un espace, la commande d'installation échoue.