Nvm-windows: ne fonctionne pas avec .nvmrc

.nvmrc n'a jamais été pris en charge. C'est une fonctionnalité spécifique à nvm, pas à NVM pour Windows.

@coreybutler Je suis du Disaster Accountability Project et nous avons des développeurs qui utilisent Windows et ne peuvent pas profiter du .nvmrc . Nous commençons à adopter nvm-windows pour nos développeurs Web bénévoles et j'aimerais que vous reconsidériez le soutien de .nvmrc . C'est le site sur lequel nous utilisons .nvmrc.

@inunotaisho26 - Fondamentalement, ce projet se concentre sur la préparation de Node comme s'il était installé de la même manière que Node serait installé sans gestionnaire de version. .nvmrc commence à s'intéresser à des problèmes spécifiques de gestion de l'environnement, ce qui augmente considérablement la portée du projet. Je vois la "gestion de l'environnement" comme un problème fondamentalement différent de la "gestion des versions". Nous avons discuté de ces différents cas d'utilisation dans le groupe de travail sur la gestion des versions .

Bien que cette fonctionnalité ait déjà été demandée, ce n'est pas quelque chose que j'ai suffisamment de temps libre pour prendre en charge. En raison du nombre de personnes qui demandent des solutions générales de gestion de l'environnement (au-delà de .nvmrc), j'expérimente des idées pour une application de gestion de l'environnement commerciale pour rationaliser ces processus. Le temps nécessaire pour soutenir la grande liste de souhaits de la communauté nécessitera un financement ou un parrainage, je vais donc probablement m'appuyer sur l'infrastructure que j'ai déjà construite pour Fenix . Le hic : pas d'ETA.

Cela dit, voir la feuille de route . La solution "gratuite" que j'ai proposée est un système de hook, similaire à celui de git pre-commit , post-push , etc. Cela permettrait aux développeurs de créer leurs propres scripts adaptés à leurs propres environnements uniques. Pensez à des actions comme post-install , pre-use , pre-execute , etc. Cela permettrait aux utilisateurs d'écrire un script hook qui recherche un fichier .nvmrc et change de version à la volée .

@coreybutler Donc, en gros, deux approches différentes pour installer plusieurs versions de nœud, n'est-ce pas?

Sorte de. Il existe deux philosophies différentes, mais elles concernent davantage l'utilisation de Node que son installation.

Philosophie 1 : Utilisation native (processus direct)
Le nœud lui-même ne prend pas en charge .nvmrc . Il installe simplement son propre exécutable et npm. C'est _utilisé_ en exécutant directement node.exe.

Philosophie 2 : Utilisation augmentée (Sous-processus)
.nvmrc est une convention introduite par le projet nvm d'origine. Au lieu d'appeler directement node.exe, il utilise une cale. Le shim est responsable de la configuration d'un pseudo-environnement avant de passer des commandes à l'exécutable du nœud (c'est-à-dire que le nœud est un sous-processus du shim). C'est là que la logique .nvmrc est traitée. Le hic, en particulier sous Windows, est que le nœud s'exécute dans le contexte du shim, au lieu du contexte de l'utilisateur. Cela a un certain nombre d'effets/défis, tels que le fait de ne pas toujours transmettre les informations d'identification appropriées au sous-processus de nœud (principalement autour d'autorisations élevées), des variables d'environnement légèrement différentes, de ne pas toujours reconnaître les partitions de disque dur (comme un lecteur D:\) et (dans certains cas) des chemins de fichiers erronés (c'est- __dirname dire que

La gestion générale des versions nécessite un certain niveau de calage afin d'empêcher la désinstallation/réinstallation du nœud à chaque fois que vous devez changer de version (ce qui prendrait une éternité). NVM4W s'aligne sur la première approche en utilisant des liens symboliques pour caler le _répertoire_ d'installation, par opposition à l'option 2, qui cale l'exécutable. Par conséquent, vous exécutez toujours l'exécutable node.exe directement, au lieu de l'exécuter en tant que sous-processus.

Petite bosse à ce problème. Je viens de tomber dessus.

Ça ne peut pas être si dur que ça. Voici ce qu'il faut faire si une version n'est pas fournie à nvm use :

1. Prendre la version de .nvmrc
2. Cette version est-elle installée ? Sinon -> installez-le
3. Cette version est-elle actuellement utilisée ? Sinon -> utilisez-le.
4. Terminé

En d'autres termes, sans numéro de version spécifié, nvm use est une combinaison de nvm install < .nvmrc et nvm use < .nvmrc (pseudo commande - ne fonctionnera pas pour le moment).

Il n'y a pas grand-chose de plus.

Petite bosse à ce problème. Je viens de tomber dessus.

Ça ne peut pas être si dur que ça. Voici ce qu'il faut faire si une version n'est pas fournie à nvm use :

1. Take version from .nvmrc

2. Is this version installed? If not -> install it

3. Is this version currently in use? If not -> use it.

4. Done

En d'autres termes, sans numéro de version spécifié, nvm use est une combinaison de nvm install < .nvmrc et nvm use < .nvmrc (pseudo commande - ne fonctionnera pas pour le moment).

Il n'y a pas grand-chose de plus.

Je suis content de ne pas être le seul à avoir ce problème...
Je pense revenir à Linux pour développer :/

@thany @jeromemeichelbeck N'hésitez pas à bifurquer le projet et à ajouter cette fonctionnalité vous-même. Je posterai un lien ici quand il sera prêt.