[] Моя установка Windows не на английском языке.
[x] прочтите README, чтобы узнать о проблемах с npm и антивирусах.
[x] убедился, что это не вопрос о том, как использовать NVM для Windows, поскольку gitter используется для вопросов и комментариев.
[] settings.txt
Тот же результат, что и nvm use 4.4.4
Вывод: node v (64-bit) is not installed.
создал файл .nvmrc
с 4.4.4
в качестве версии узла.
перейдите в командную строку и запустите nvm use
в той же папке, что и файл.
.nvmrc
никогда не поддерживался. Это особенность nvm, а не NVM для Windows.
@coreybutler Я из проекта Disaster Accountability Project, и у нас есть разработчики, которые используют Windows и не могут воспользоваться преимуществами .nvmrc
. Мы начинаем принимать nvm-windows
для наших добровольных веб-разработчиков, и я хотел бы, чтобы вы пересмотрели вопрос о поддержке .nvmrc
. Это сайт, на котором мы используем .nvmrc.
@ inunotaisho26 - По сути, этот проект направлен на подготовку Node, как если бы он был установлен так же, как Node, без диспетчера версий. .nvmrc
начинает вникать в конкретные проблемы управления средой, что резко увеличивает объем проекта. Я считаю, что «управление средой» - это принципиально другая проблема, чем «управление версиями». Мы обсудили эти различные варианты использования в рабочей группе по управлению версиями .
Хотя эта функция запрашивалась и раньше, у меня недостаточно свободного времени для поддержки. Из-за большого количества людей, которые запрашивают общие решения для управления средой (помимо .nvmrc), я экспериментирую с идеями коммерческого приложения для управления средой, чтобы упростить эти процессы. Временные требования для поддержки большого списка желаний сообщества потребуют финансирования или спонсорства, поэтому я, вероятно, буду опираться на инфраструктуру, которую я уже построил для Fenix . Уловка: нет ETA.
Тем не менее, см. Дорожную карту . «Бесплатное» решение, которое я предложил, представляет собой систему ловушек, аналогичную git pre-commit
, post-push
и т. Д. Это позволило бы разработчикам создавать свои собственные сценарии, подходящие для их собственных уникальных сред. Подумайте о таких действиях, как post-install
, pre-use
, pre-execute
и т. Д. Это позволило бы пользователям написать сценарий ловушки, который ищет файл .nvmrc и на лету переключает версию. .
@coreybutler Итак, по сути, это два разных подхода к установке нескольких версий узла, верно?
Вроде, как бы, что-то вроде. Есть две разные философии, но они больше связаны с _использованием_ Node, чем с его установкой.
Философия 1: Собственное использование (прямой процесс)
Сам узел не поддерживает .nvmrc
. Он просто устанавливает собственный исполняемый файл и npm. Он _используется_ прямым запуском node.exe.
Философия 2: Расширенное использование (подпроцесс)
.nvmrc
- это соглашение, введенное исходным проектом nvm. Вместо прямого вызова node.exe он использует прокладку. Прокладка отвечает за настройку псевдосреды перед передачей команд исполняемому файлу узла (т. Е. Узел является подпроцессом прокладки). Здесь обрабатывается логика .nvmrc
. Уловка, особенно в Windows, заключается в том, что узел запускается в контексте прокладки, а не в контексте пользователя. Это имеет ряд эффектов / проблем, таких как не всегда передача соответствующих учетных данных в подпроцесс узла (в основном в отношении повышенных разрешений), несколько другие переменные среды, не всегда распознавание разделов жесткого диска (например, диск D: \) и (в в некоторых случаях) неверные пути к файлам (например, __dirname
ведет себя неожиданно) и т. д. Эти проблемы можно обойти, но они устраняются при рассмотрении корпоративной среды (развертывание Active Directory, рабочие столы с ограниченным доступом, диски SAN и т. д.).
Для общего управления версиями требуется некоторый уровень проклейки, чтобы предотвратить фактическое удаление / переустановку узла каждый раз, когда вам нужно переключить версию (что займет вечность). NVM4W согласуется с первым подходом, используя символические ссылки для установки оболочки _directory_, в отличие от варианта 2, который устанавливает оболочку для исполняемого файла. В результате вы всегда запускаете исполняемый файл node.exe напрямую, а не как подпроцесс ..
Небольшой удар в этом вопросе. Просто столкнулся с этим.
Это не может быть серьезно. Вот что делать, если в nvm use
не указана версия:
Другими словами, без указания номера версии nvm use
представляет собой комбинацию nvm install < .nvmrc
и nvm use < .nvmrc
(псевдокоманда - сейчас не будет работать).
Больше нечего.
Небольшой удар в этом вопросе. Просто столкнулся с этим.
Это не может быть серьезно. Вот что делать, если в
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
Другими словами, без указания номера версии
nvm use
представляет собой комбинациюnvm install < .nvmrc
иnvm use < .nvmrc
(псевдокоманда - сейчас не будет работать).Больше нечего.
Я рад, что не только у меня возникла эта проблема ...
Думаю вернуться на Linux для разработки: /
@thany @jeromemeichelbeck Не стесняйтесь разветвлять проект и добавлять эту функциональность самостоятельно. Я выложу здесь ссылку, когда она будет готова.
Самый полезный комментарий
Небольшой удар в этом вопросе. Просто столкнулся с этим.
Это не может быть серьезно. Вот что делать, если в
nvm use
не указана версия:Другими словами, без указания номера версии
nvm use
представляет собой комбинациюnvm install < .nvmrc
иnvm use < .nvmrc
(псевдокоманда - сейчас не будет работать).Больше нечего.