Nvm-windows: Prise en charge de .nvmrc

Je ne pense pas que ce soit une voie que je veuille emprunter. La principale raison est que cela nécessiterait un piratage très laid pour recréer/imiter le binaire du nœud. Par exemple, appeler node index.js signifie que le node.exe piraté/falsifié devra d'abord analyser le fichier package.json (s'il existe même) pour déterminer la version, puis exécuter le vrai node.exe pour la version appropriée.

Certains autres projets similaires ont tenté d'utiliser des fichiers .bat pour accomplir cela. Cette approche est fragile, et elle va à l'encontre de l'objectif premier de l'architecture .

Je ne pense pas non plus que la demande soit généralisée pour cela.

La prise en charge de .nvmrc est un aspect assez important de l'utilisation de NVM avec un système CI. Je ne lie pas la suggestion package.json, d'autant plus qu'elle rompt la compatibilité avec nvm, mais une pull request avec prise en charge de .nvmrc serait-elle acceptée ?

@ gruber76 - Je n'accepterai probablement pas de relations publiques à ce sujet.

.nvmrc , package.json ... ils nécessitent tous les deux le même hack méchant.

@coreybutler Je ne suis pas sûr de comprendre votre raison de ne pas vouloir soutenir cela. Cette fonctionnalité n'aurait-elle pas simplement pour effet de rechercher dans le fichier .nvmrc chaque fois que nvm est invoqué sans spécifier de numéro de version ? Par conséquent, de quels hacks méchants parlez-vous?

Le méchant hack : réécrire les liens symboliques pour Windows.

NVM pour Windows fonctionne en remplaçant la cible du lien symbolique par le répertoire d'installation du nœud physique souhaité. Il s'agit d'un changement à l'échelle du système.

Disons que vous lancez un script en spécifiant la version 0.12.0 dans un fichier .nvmrc , puis lancez un deuxième script sans .nvmrc . Le lien symbolique pointerait vers la v0.12.0 (à partir de la première instanciation). Si le 2ème script nécessite autre chose (comme v4.2.6) sans .nvmrc , il échouera. Cela introduit une instabilité de l'environnement lors de l'utilisation de liens symboliques car il n'y a pas de véritable isolation de processus.

La seule façon de vraiment isoler une version par processus est de rediriger nvm.exe vers la version demandée par le script au lieu de permettre au système d'exploitation de le faire. Je ne veux vraiment pas recréer quelque chose que le système d'exploitation fait déjà pour nous.

Si les gens veulent vraiment utiliser une approche par processus/projet, une solution plus appropriée consiste à isoler l'environnement d'exécution. Personnellement, j'utilise Docker pour ça.

Pardonnez-moi pour mon ignorance, ici. Mon cas d'utilisation principal est le développement d'applications node/web en utilisant bower/grunt/gulp, etc. avec plusieurs équipes. Pour moi, il est extrêmement rare que plusieurs versions s'exécutent à moins de cinq minutes d'intervalle. Pour ce cas d'utilisation, le fichier .nvmrc est la façon dont mes équipes spécifient quel nœud doit faire.

J'ai du mal à voir dans la situation que vous décrivez (script A par rapport au script B) à quel point la prise en charge de .nvmrc serait plus gênante que d'avoir le script A (ou un utilisateur du script A) appelant nvm pour définir la version, puis en oubliant de définir avant d'exécuter le script B. Mais je suppose qu'il existe des cas d'utilisation courants pour nvm qui sont beaucoup plus difficiles que le mien. Peut-être, par exemple, si mes serveurs CI avaient une charge plus lourde.

J'ai une solution de contournement à offrir à quiconque en a besoin. Ce qui suit dans un script bat pré-exécuté :

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

Pourquoi ne pas mettre la commande nvm pour définir la version requise dans un script npm ?

Steve Lee
Envoyé depuis mon appareil mobile Veuillez excuser les fautes de frappe
Le 3 mars 2016 à 16h50, "gruber76" [email protected] a écrit :

Pardonnez-moi pour mon ignorance, ici. Mon cas d'utilisation principal est le développement
applications node/web utilisant bower/grunt/gulp, etc. avec plusieurs équipes. Pour
moi, il est extrêmement rare que j'aie plusieurs versions s'exécutant dans
cinq minutes d'intervalle. Pour ce cas d'utilisation, le fichier .nvmrc est la façon dont mon
les équipes spécifient ce que le nœud doit faire.

J'ai du mal à voir dans la situation que vous décrivez (script A versus
script B) comment supporter .nvmrc serait plus gênant que d'avoir
script A (ou un utilisateur du script A) appelant nvm pour définir la version puis
oublier de le définir avant d'exécuter le script B. Mais je suppose qu'il y a
quelques cas d'utilisation courants pour nvm qui sont beaucoup plus durs que le mien.
Peut-être, par exemple, si mes serveurs CI avaient une charge plus lourde.

J'ai une solution de contournement à offrir à quiconque en a besoin. Les
suivant dans un script bat pré-exécuté :

définir /p nodev=<.nvmrc
nvm installer %nodev%
nvm utilise %nodev%

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/coreybutler/nvm-windows/issues/128#issuecomment-191852401
.

La prise en charge du fichier .nvmrc serait vraiment utile. Nous avons de nombreux projets, et ils n'exécutent pas tous la même version de node. Le fichier .nvmrc est à la racine de chaque référentiel pour garantir que la version correcte du nœud est utilisée pour un projet donné.

En passant, il est également assez ennuyeux que nvm install doive être suivi de nvm use . Je suis curieux de connaître le raisonnement derrière l'exigence de la deuxième étape après une installation. Je peux voir en quoi l'installation et l'utilisation sont différentes, mais je me demande s'il existe un cas d'utilisation où quelqu'un téléchargerait et installerait, mais ne l'utiliserait pas.

Notre solution de contournement est que nous avons un fichier nommé install-node.js qui réside à la racine de chaque projet. Chaque fois que nous passons à un projet, nous exécutons node install-node partir de la ligne de commande. Le contenu du fichier install-node.js est le suivant :

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 - La séparation entre install et use était principalement pour la configuration de l'environnement de masse. J'installerai souvent plusieurs versions de node avant de basculer entre elles. Toutefois; il semble parfaitement raisonnable d'avoir un indicateur, comme nvm install -u 5.9.1 pour installer et utiliser automatiquement... ou utiliser automatiquement la version et avoir un indicateur pour _ne pas_ l'utiliser. Je vais certainement envisager d'ajouter ceci.

Pour tout le monde - Si vous avez vraiment besoin de basculer projet par projet, pensez à mettre nvm use x.x.x && node index.js dans la section npm start script de votre package.json. Une bonne pratique courante consiste à toujours utiliser npm start pour lancer une application de nœud.

Pour tout le monde - Si vous avez vraiment besoin de basculer projet par projet, pensez à mettre nvm use xxx && node index.js dans la section npm start script de votre package.json. Une bonne pratique courante consiste à toujours utiliser npm start pour lancer une application de nœud.

Cela pourrait en fait être trop tard dans le cas où des scripts npm _build_ utilisés lors de l'installation dépendent de la version node / npm. Ou d'autres outils tels que grunt etc. ou utilisez la mauvaise version causant d'autres problèmes, BTW, je suppose que l'autre meilleure pratique consiste à avoir _everything_ installé localement (c'est-à-dire pas -g) afin que les dépendances de version ne soient jamais un problème.

C'est donc une bonne pratique d'utiliser le npm install pour tout configurer. Vous pouvez ensuite ajouter une étape de préinstallation pour utiliser nvm use. par exemple ajouter

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

Cela devrait être OK même si la version d'origine de npm s'exécutera dans le processus parent. L'étape d'installation lancera un nouveau shell afin que toutes les actions doivent récupérer le nouveau nœud et npm.

Vous voudrez peut-être même ajouter une étape de pré-démarrage à celle des installations.

@SteveALee - oui, vous avez raison, ma suggestion précédente ne fonctionnerait pas. Il serait trop tard dans le processus pour lancer de manière fiable.

@coreybutler À la fin, j'ai

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

Peut-être qu'une option nvm use -i x.x.x serait bonne ? C'est-à-dire installer si ce n'est déjà fait ?

Je voudrais suggérer de mettre en œuvre au moins une partie de ceci :

Sous Linux / Mac, dans un dossier contenant un fichier .nvmrc , je peux exécuter nvm use sans spécifier de version concrète, et la version installée qui correspond au contenu de .nvmrc obtient activé. Si le fichier indique 8 , la dernière version installée de Node 8 est installée.

Je combine cela sur mes systèmes avec un script qui surcharge cd afin que je puisse cd dans un répertoire et que la bonne version du nœud soit activée, avec ce script dans .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'; }

Cela pourrait aussi facilement fonctionner sous Windows, si nvm respectait ces fichiers.

Un .nvmrc ne sera pas implémenté par défaut. Toutefois; la feuille de route contient un plan de prise en charge des hooks (https://github.com/coreybutler/nvm-windows/issues/190). Un script pre-use peut être utilisé pour ajuster la version en fonction du fichier souhaité (y compris package.json, .nvmrc ou tout autre fichier de votre choix).

Étant donné que ce problème semble être presque mort, j'ai un script Powershell de contournement qui devrait imiter les fonctionnalités de "nvm use" et "nvm install" si le fichier .nvmrc contient une version de nœud à un chiffre.

nvm install (Get-Content .nvmrc) fonctionnerait bien, mais nvm use (Get-Content .nvmrc) ne fonctionnera pas (car lorsqu'une version à un chiffre est transmise à l'installation, elle installe la révision la plus récente de cette version de nœud mais nvm use avec un seul chiffre lui ajoute '.0.0' au lieu d'obtenir le plus récent.

@coreybutler Si vous mettez à jour la commande "use" dans nvm.go pour utiliser le même code que install , cela rendrait ce correctif inutile (c'est-à-dire):
if len(version) == 1 { version = findLatestSubVersion(version) } else { version = cleanVersion(version) }

Le script suivant utilisera "nvm list available" et filtrera la liste pour la version LTS la plus élevée qui correspond à la version du fichier .nvmrc, puis l'utilisera "nvm". S'il n'est pas installé, il 'nvm install's it puis '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())

Je veux juste demander le support de nvm pour lire à partir d'un fichier .nvmrc. Cela rendrait vraiment mon expérience de développement de nœuds entre Mac et Windows transparente.

Est-ce fermé parce qu'il a été corrigé ou ne va pas être modifié ?

Existe-t-il une autre version compatible Windows de nvm qui utilise la même API que les versions *nix ?