Nvm-windows: Поддержка .nvmrc

Я не думаю, что это тот маршрут, по которому я хочу идти. Основная причина в том, что для воссоздания / имитации двоичного файла узла потребуется очень уродливый взлом. Например, вызов node index.js означает, что взломанный / подделанный node.exe должен сначала проанализировать файл package.json (если он вообще существует), чтобы определить версию, а затем выполнить настоящий node.exe для соответствующей версии.

В некоторых других подобных проектах для этого пытались использовать файлы .bat . Такой подход хрупок и противоречит основной цели архитектуры .

Я также просто не думаю, что спрос на это широко распространен.

Поддержка .nvmrc - довольно важный аспект использования NVM с системой CI. Я не связываю предложение package.json, тем более что оно нарушает совместимость с nvm, но будет ли принят запрос на перенос с поддержкой .nvmrc?

@ gruber76 - Я, наверное, не приму пиара по этому

.nvmrc , package.json ... они оба требуют одного и того же мерзкого взлома.

@coreybutler Я не уверен, что понимаю ваше обоснование нежелания поддерживать это. Не могла бы эта функция просто откатиться к просмотру файла .nvmrc всякий раз, когда nvm вызывается без указания номера версии? Следовательно, о каких мерзких хаках вы говорите?

Гадкий прием: переписать символические ссылки для Windows.

NVM для Windows работает, изменяя цель символической ссылки на желаемый каталог установки физического узла. Это общесистемное изменение.

Допустим, вы запускаете сценарий, указав версию 0.12.0 в файле .nvmrc , а затем запускаете второй сценарий без .nvmrc . Символьная ссылка будет указывать на v0.12.0 (из первого экземпляра). Если второй сценарий требует чего-то еще (например, v4.2.6) без .nvmrc , он завершится ошибкой. Это приводит к нестабильности среды при использовании символических ссылок, потому что нет настоящей изоляции процесса.

Единственный способ по-настоящему изолировать версию для каждого процесса - это перенаправить nvm.exe на версию, запрашиваемую сценарием, вместо того, чтобы позволить операционной системе сделать это. Я действительно не хочу воссоздавать то, что операционная система уже делает для нас.

Если люди действительно хотят использовать подход к каждому процессу / проекту, более подходящим решением является изоляция среды выполнения. Лично я для этого использую Docker.

Простите меня за мое невежество, здесь. Мой основной вариант использования - разработка узловых / веб-приложений с использованием bower / grunt / gulp и т. Д. С несколькими командами. Для меня крайне редко, когда у меня запускаются несколько версий с интервалом в пять минут друг от друга. Для этого варианта использования файл .nvmrc - это то, как мои команды определяют, что должен делать узел.

В описываемой вами ситуации (сценарий A по сравнению со сценарием B) мне трудно понять, что поддержка .nvmrc была бы более проблематичной, чем использование сценария A (или пользователя сценария A), вызывающего nvm для установки версии, а затем забывающего установить это перед запуском скрипта B. Но я предполагаю, что есть несколько распространенных случаев использования nvm, которые намного сложнее, чем у меня. Возможно, например, если мои серверы CI имели большую нагрузку.

У меня есть обходной путь, который я могу предложить всем, кто в нем нуждается. Следующее в предварительно запущенном сценарии летучей мыши:

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

Почему бы не использовать команду nvm для установки необходимой версии в сценарии npm?

Стив Ли
Отправлено с моего мобильного устройства Пожалуйста, извините за опечатки
3 марта 2016 г., 16:50, «gruber76» [email protected] написал:

Простите меня за мое невежество, здесь. Мой основной вариант использования находится в стадии разработки
node / веб-приложения, использующие bower / grunt / gulp и т. д. с несколькими командами. Для
мне крайне редко, когда у меня будет несколько версий, работающих в
пять минут друг друга. Для этого варианта использования файл .nvmrc - это то, как мой
команды указывают, что узел должен делать.

Мне сложно понять описанную вами ситуацию (сценарий A против
скрипт B), что поддержка .nvmrc будет труднее, чем наличие
сценарий A (или пользователь сценария A) вызывает nvm для установки версии, а затем
забывая установить его перед запуском скрипта B. Но я предполагаю, что есть
некоторые распространенные варианты использования nvm, которые намного сложнее, чем у меня.
Возможно, например, если мои серверы CI имели большую нагрузку.

У меня есть обходной путь, который я могу предложить всем, кто в нем нуждается. В
следующее в предварительно запущенном сценарии летучей мыши:

установить / p nodev = <. nvmrc
nvm install% nodev%
nvm использует% nodev%

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/coreybutler/nvm-windows/issues/128#issuecomment -191852401
.

Поддержка файла .nvmrc была бы действительно полезной. У нас много проектов, и не все они используют одну и ту же версию node. Файл .nvmrc находится в корне каждого репо, чтобы гарантировать, что для данного проекта используется правильная версия узла.

В качестве примечания: также раздражает то, что за nvm install должно следовать nvm use . Мне любопытно узнать, почему требуется второй шаг после установки. Я вижу, что установка и использование - это разные вещи, но мне интересно, есть ли когда-нибудь вариант использования, когда кто-то будет загружать и устанавливать, но не использовать.

Наш обходной путь заключается в том, что у нас есть файл с именем install-node.js который находится в корне каждого проекта. Всякий раз, когда мы переключаемся на проект, мы запускаем node install-node из командной строки. Содержимое файла install-node.js выглядит следующим образом:

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 - Разделение между install и use основном предназначалось для массовой конфигурации среды. Я часто устанавливаю несколько версий узла, прежде чем переключаться между ними. Тем не мение; кажется вполне разумным иметь флаг, например nvm install -u 5.9.1 для установки и автоматического использования ... или автоматически использовать версию и иметь флаг для _не_ использования. Я обязательно подумаю о добавлении этого.

Для всех - если вам действительно нужно переключаться на отдельный проект, подумайте о том, чтобы добавить nvm use x.x.x && node index.js в раздел сценария запуска npm вашего package.json. Распространенная передовая практика - всегда использовать npm start для запуска приложения узла.

Для всех - если вам действительно нужно переключаться для каждого проекта, подумайте о том, чтобы поместить nvm use xxx && node index.js в раздел сценария запуска npm вашего package.json. Распространенная передовая практика - всегда использовать npm start для запуска приложения узла.

На самом деле это может быть слишком поздно для любых сценариев npm _build_, используемых во время установки, которые зависят от версии node / npm. Или другие инструменты, такие как grunt и т. Д., Работают явно. Они могут выйти из строя во время установки с неправильной версией node / npm. или используйте неправильную версию, вызывающую другие проблемы, кстати, я предполагаю, что другая передовая практика - установить _everything_ локально (т.е. не -g), поэтому зависимости версий никогда не будут проблемой.

Таким образом, рекомендуется использовать npm install для настройки всего. Затем вы можете добавить этап предварительной установки, чтобы использовать nvm use. например добавить

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

Это должно быть нормально, даже если исходная версия npm будет работать в родительском процессе. На этапе установки будет запущена новая оболочка, поэтому все действия должны выбрать новый узел и npm.

Возможно, вы даже захотите добавить предварительный этап, чем установка.

@SteveALee - да, ты прав, мое предыдущее предложение не сработало. Было бы слишком поздно для надежного запуска.

@coreybutler В конце концов я пошел на это

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

Возможно, nvm use -i x.x.x вариант

Я предлагаю реализовать хотя бы часть этого:

В Linux / Mac в папке с файлом .nvmrc я могу запустить nvm use без указания конкретной версии, и установленная версия, которая соответствует содержимому .nvmrc получит активирован. Если в файле написано 8 , то будет установлена ​​последняя установленная версия Node 8.

Я комбинирую это в своих системах со сценарием, который перегружает cd так что я могу cd в каталог и активировать нужную версию узла, с этим сценарием в .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'; }

Это могло бы легко работать и в Windows, если бы nvm уважал эти файлы.

.Nvmrc не будет реализован по умолчанию. Тем не мение; в дорожной карте есть план поддержки хуков (https://github.com/coreybutler/nvm-windows/issues/190). Сценарий pre-use может использоваться для корректировки версии в соответствии с любым файлом, который они хотят (включая package.json, .nvmrc или что-нибудь еще по вашему выбору).

Поскольку эта проблема кажется почти устраненной, у меня есть обходной сценарий Powershell, который должен имитировать функциональность «nvm use» и «nvm install», если файл .nvmrc содержит версию узла с однозначным числом.

nvm install (Get-Content .nvmrc) будет работать нормально, однако nvm use (Get-Content .nvmrc) не будет работать (потому что, когда для установки передается однозначная версия, она устанавливает самую последнюю версию этой версии узла, но nvm use с одна цифра добавляет к нему «.0.0» вместо самого последнего.

@coreybutler Если вы install , это исправление станет ненужным (т.е.):
if len(version) == 1 { version = findLatestSubVersion(version) } else { version = cleanVersion(version) }

Следующий скрипт будет использовать «nvm list available» и отфильтровать список для наивысшей версии LTS, которая соответствует версии файла .nvmrc, а затем «nvm использует» его. Если он не установлен, то это «nvm install», затем «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())

Просто хочу запросить поддержку использования nvm для чтения из файла .nvmrc. Это действительно сделало бы мой опыт разработки узлов между Mac и Windows безупречным.

Это закрыто, потому что это было исправлено или не будет изменено?

Есть ли другая Windows-совместимая версия nvm которая использует тот же API, что и версии * nix?