Nvm-windows: Неправильная папка для установки

Я ошибаюсь, или NVM просто поместил кэш пакетов узлов размером 400 МБ в мой перемещаемый профиль?

Нет, это ошибка в NPM.

Установка по умолчанию указывает на каталог appdata локального пользователя, а не на роуминг. Хотя может быть лучше разместить исполняемый файл в другом месте, все файлы установки узла и npm считаются данными для NVM (это дизайн npm). Опять же, это значения по умолчанию по какой-то причине ... вы можете изменить их, если они вам не нравятся.

Понятия не имею, откуда у вас 400 МБ. Можете ли вы предоставить более подробную информацию о своей среде?

По первому пункту, возможно, разница в том, что я устанавливаю его на компьютер, подключенный к домену, а вы нет. Но в любом случае это все равно неверно. AppData предназначен для пользовательских настроек, а не для исполняемых файлов.

Что касается второго пункта, то ошибку совершает сам Node. Я запишу баг с ними отдельно.

Это не обязательно «неправильно», но если это имеет неблагоприятные последствия, я буду рад рассмотреть ваш вариант использования. У меня не было такого опыта с компьютером, подключенным к домену, поэтому, опять же, подробности среды помогут мне понять ваш конкретный вариант использования.

Например, если я знаю, что искать, я могу сделать следующую версию установщика зависимой от домена. Другими словами, место установки по умолчанию может быть более разумным.

Вот основные рекомендации:

• Программы идут в %ProgramFiles% , обычно это C:\Program Files .
• На 64-битной машине старые программы x86 помещаются в %ProgramFiles(x86)% , обычно это C:\Program Files (x86) .
• Машинные программные данные, такие как кеши пакетов, помещаются в %ProgramData% , что обычно C:\ProgramData
• Пользовательские настройки, которые можно безопасно перемещать с машины на машину, занимают %APPDATA%
• Пользовательские настройки, которые являются локальными для данной машины (например, те, которые содержат пути установки), входят в %LOCALAPPDATA% .

Исполняемые файлы нередко находятся в appdata. Приложения, установленные с помощью clickonce, делают это, это программа установки от Microsoft. Chrome делает это. Многие вещи так делают.

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

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

Я считаю, что мой недавний опыт имеет отношение к обсуждению: недавно у меня был коммутатор рабочей станции. Пути для node_packages в моем перемещаемом профиле были настолько глубокими, что восстановление перемещаемого профиля, которое пыталась выполнить моя машина, терпело неудачу каждый раз, пока я не удалил папку node_packages. Эти ошибки появлялись в журналах событий Windows. После того, как я это сделал, моя новая рабочая станция наконец смогла синхронизировать мой перемещаемый профиль.

Я согласен с тем, что установка в роуминге вызывает проблемы, когда вы работаете с компаниями, которые создают резервную копию вашего профиля для использования в своих сетях. Например, моему компьютеру требуется 30 минут для выключения и 30 минут для перезагрузки; все из-за модулей npm. К сожалению, AFAIK, это проблема самого NPM.

В продолжение этого:

В общем, важно отметить, что любой менеджер версий просто управляет программами. Я повторяю предыдущий комментарий .... в смысле NVM установленная программа (узел) _is_ данные. То, как вы его используете (например, модули npm), может влиять на след.

@ sam3k правильно, что след определенно связан с тем, как npm был соизволен, и на самом деле NVM не так уж много _должен_ сделать для этого, да и сам npm не может сделать для этого много. Все сводится к знанию того, что вы устанавливаете, и любой менеджер пакетов позволяет легко принять это как должное. Многие люди не обращают внимания на размер модулей, что является проблемой качества кода / среды, присущей миру с открытым исходным кодом. В итоге, сообщество должно решить эту проблему с помощью дисциплинированных методов кодирования (далеко не тривиальная задача). Я один из многих, кто выступал за это (см. Npm нуждается в персональном тренере . Суть: управление npm выходит за рамки базовой предпосылки управления используемой версией узла.

У @aljones и @ygra есть хорошие моменты. Я не возражаю с ними, но хочу напомнить всем, что для работы символических ссылок необходимы административные привилегии. Это основной принцип работы NVM для Windows.

У @cokobware есть то, что я считаю распространенной проблемой в корпоративных средах. Суть в том, что npm не был разработан для легкой переносимости при большом масштабе. Один экземпляр node + npm уже довольно тяжелый, не говоря уже о добавлении нескольких версий. Независимо от того, как данные / файлы перемещаются с рабочей станции на рабочую станцию, их чертовски много, что на это потребуется время. Возможны варианты: использовать перемещаемые профили Windows, заархивировать все и передать вручную или повторно загрузить из реестра npm. Независимо от того, как вы его раскручиваете, для синхронизации рабочей станции потребуется время, чтобы собрать все биты в нужное место.

Будущее NVM для Windows (на данный момент), вероятно, по-прежнему будет сосредоточено на переключении версий узлов. Я могу даже изменить название проекта, чтобы отразить это. Он будет по-прежнему предоставлять установщику стандартные значения по умолчанию, но организация / разработчик по-прежнему может переопределить эти значения по умолчанию способом, подходящим для своей организации. Я рассматриваю управление версиями узлов как проблему, явно отличающуюся от управления следами npm, хотя я экспериментирую с способами, с помощью которых NVM4W может предоставить хуки для лучшего управления npm.

Следуйте предложению @Grauenwolf и этим ссылкам: руководство по развертыванию , CSIDL и переменные среды

• символическая ссылка% USERPROFILE% AppData на% PROGRAMFILES% или% PROGRAMFILES (X86)% - плохая идея. Проблема с несколькими пользователями (проблема с правом собственности. Другой пользователь не может получить доступ к ссылке).
• Программа nvm должна храниться в% PROGRAMFILES% или% PROGRAMFILES (X86)%.
• Репозиторий nodejses должен храниться в% PROGRAMDATA%, поскольку область действия - все пользователи.
• активная ссылка nodejs должна храниться в% LOCALAPPDATA%, поскольку область действия предназначена для каждого пользователя.

NVM не может быть установлен в% PROGRAMFILES% из-за других ошибок. Если вы поместите его в папку, в имени которой есть пробел, команда установки завершится ошибкой.