Запуск sudo npm install -g кажется довольно распространенным советом в Интернете. Mean.io, известный генератор / библиотека компиляции веб-фреймворков, даже предлагает сделать это на своей домашней странице.

Использование sudo npm install (и потенциально sudo npm <anything>) - плохая идея ™. Это проблема как минимум по нескольким причинам:

  • npm install может запускать произвольные скрипты. Из-за того, как настроен npm, и того факта, что вы можете изменять реестр и использовать DNS, возможно, что вы случайно установите вредоносный пакет в целом, установите вредоносный пакет, маскирующийся под совершенно допустимый пакет, или установите пакет с добрыми намерениями, который может запускать сценарии, которые каким-то образом вредят вашей системе, если запускаться от имени пользователя root.
  • Запуск sudo npm install (без -g) создаст локальный каталог, который может быть изменен только пользователем root. Это действительно может испортить вам жизнь, если вы попытаетесь сделать npm <something> в том же каталоге или проекте позже.
  • Даже sudo npm install -g с допустимой целью установки может испортить вам ситуацию и затруднить использование npm без sudo при некоторых обстоятельствах в будущем, особенно если вы измените npm конфигурацию на промежуточном этапе. Пользователь root может и будет создавать файлы в вашем кеше npm и, возможно, такой файл, как ~/.npm/_locks, и в будущем npm install или npm install -g выдаст вам ужасную ошибку EACCES.

Поэтому, когда дело доходит до использования sudo с npm: просто не делайте этого.

npm install -g для себя

Большую часть времени вы, вероятно, будете работать в системе, которая требует, чтобы только один пользователь использовал узел и глобально установленные двоичные файлы (вы сами на своем компьютере, какой-то node пользователь на серверах). Самое простое решение проблемы npm install -g - просто изменить место установки узловых модулей.

Явный префикс

npm использует параметр prefix, чтобы определить, где установить глобально - или, по крайней мере, то, что он вызывает глобально. Вы можете увидеть, какой префикс установлен, запустив npm prefix -g, и это, вероятно, что-то вроде /usr. Это нежелательно. Вместо этого было бы неплохо глобально установить модули узлов в каталог, к которому текущий пользователь имеет доступ.

npm --prefix=/home/your-user/.global-node-modules install -g grunt-cli

Конечно, вы можете изменить префикс на все, что захотите. Также было бы ужасно мучительно набирать этот --prefix параметр каждый раз, поэтому, к счастью, существует .npmrc файл, который npm будет использовать для проверки значений по умолчанию. Мой выглядит так:

# ~/.npmrc tmp=/home/ajcrites/files/node-tmp cache=/home/ajcrites/.npmcache prefix=/home/ajcrites/.npm

Конечно, вы можете выбрать любые значения, которые захотите. Полный список всех настроек конфигурации, которые вы можете применить к команде npm или задать в .npmrc, указан с npm help 7 config (для поиска потребовалось некоторое время).

В любом случае, как только вы выберете несколько хороших скрытых папок, npm install -g перестанет класть всевозможный мусор в ваш домашний каталог, /usr каталог и различные другие места, когда вы запустите npm install -g (и npm install в некоторых случаях ).

К сожалению, похоже, что нет настройки конфигурации, куда поместить npm-debug.log ... пока.

Таким образом, установка prefix в .npmrc или просто использование --prefix позволит вам использовать npm install -g без sudo.

Но подождите! Вы также должны убедиться, что двоичные файлы находятся на вашем пути. Просто добавьте $PREFIX/bin к своему пути. Так что в моем случае:

# .zshrc / .bashrc / .profile / etc. export PATH=$PATH:$HOME/.npm/bin export NODE_PATH=$NODE_PATH:$HOME/.npm/lib/node_modules

Обратите внимание, что установка NODE_PATH заставит node проверять этот путь на наличие библиотек. Больше информации здесь, и это может быть, а может и не всегда быть желательным. Я просто включил его для полноты картины.

Использование nvm

Настройка .npmrc и $PATH может потребовать много работы. Ну, не совсем, но представьте, что это так.

Также помните, что ваша текущая версия _52 _ / _ 53_ имеет значение. Некоторые библиотеки могут поддерживать или применять только требование v0.10, тогда как вы можете использовать v0.12 в своей системе.

nvm - отличный пакет, который требует очень небольшой настройки и позволяет легко устанавливать и переключаться между версиями узла. Вы даже можете добавить nvm use <specific-version> в свой профиль, если вы много работаете с определенной версией и хотите использовать ее каждый раз при запуске оболочки.

Так почему это здорово? nvm обновляет ваш префикс! - по крайней мере, если вы его еще не установили. Он установит двоичные файлы в ~/.nvm/<version>/bin. Он также добавляет этот каталог в ваш $PATH, когда вы запускаете nvm use! И если вы снова переключитесь на nvm use system или другую версию, она удалит ее соответствующим образом.

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

Обратите внимание, что nvm делает это, только если в вашем .npmrc не задано значение prefix. Конечно, вы все еще можете отменить все с помощью npm --prefix. Если у вас prefix в вашем .npmrc или используется --prefix, то npm install -g, использованный после nvm use, по-прежнему будет использовать ваши настройки префикса. Я думаю, что обычно это хорошо.

Я столкнулся с небольшими проблемами, когда nvm не был получен должным образом. Вам просто нужно сделать source /path/to/nvm/nvm.sh. nvm пытается добавить это в ваш профиль автоматически, но это может не всегда работать должным образом. При необходимости обновите .zshrc, .bashrc и другие.

npm install -g для сервера

Предыдущий раздел идеально подходит для сервера, на котором вы развертываете приложение узла. Обычно на вашем сервере есть пользователь (назовите его node или как хотите), который отвечает за работу узла. Настройте их .npmrc или просто настройте свои задания сборки для использования --prefix в зависимости от ситуации.

Это все еще не вариант использования sudo npm install.

npm install -g для всех пользователей

Иногда система позволяет нескольким пользователям глобально устанавливать и использовать двоичные файлы и библиотеки пакетов узлов. по-прежнему нет причин использовать sudo для этого - по крайней мере, для команды npm.

Мое решение для этого будет заключаться в создании каталога для установки модулей глобального узла - возможно, в /var, хотя /usr может быть допустимым ... Я все еще опасаюсь этого, хотя, поскольку в /usr/bin есть вещи, не относящиеся к узлам.

sudo addgroup npm-global-installers sudo mkdir -p /usr/{bin,lib/node_modules} sudo chgrp -R npm-global-installers !$ sudo chmod -R g+w !$

!$ выше - это раскрытие истории для «последнего слова предыдущей команды» или /usr/{bin,lib/node_modules} в обоих случаях.

Это создает группу, которая может запускать npm install -g для добавления узловых модулей в /usr/lib. Вы можете добавить доверенных пользователей в эту группу в своей системе и выполнить настоящую глобальную установку узловых модулей.

Однако серьезным недостатком этого решения является то, что любой npm-global-installers может заблокировать глобальные установки других пользователей. Отдельные пользователи могут решить эту проблему, просто используя свой собственный префикс, но это противоречит цели глобальной установки.

Другое решение - просто иметь пользователя npm-global-intaller и обновить его prefix до ~/npm, а затем попросить всех добавить ~npm-global-installer/npm к своим $PATH. Другие пользователи могут выполнять эти глобальные установки, используя sudo с пользователем npm-global-installer (не root - я не тестировал это, и он все еще может сделать некоторые ~/.npm/_locks, на которые у вас нет разрешений) или этот каталог можно сделать группу / мир доступной для записи.

Оба вышеперечисленных решения позволяют нескольким пользователям использовать двоичные файлы / библиотеки пакетов узлов в масштабе всей системы.

Конечно, если вы действительно хотите использовать библиотеки, установленные другим пользователем, вы можете обновить свой $NODE_PATH, включив его. Если вы хотите использовать двоичный файл, обновите свой $PATH, чтобы включить его, или даже просто сделайте /home/other-user/path/to/node/bin/script (при условии, что вы можете его выполнить).

Я уже бегал sudo npm install. Помощь!

Если вы сталкиваетесь со странными ошибками с npm install - особенно с теми, которые говорят EACCES много после того, как вы сделали sudo npm install в прошлом, это, скорее всего, проблема с правами доступа к каталогам, которые npm пытается изменить. Это следствие npm тупости в хорошем смысле. Он с радостью попытается сделать то, что вы ему скажете, и создать файлы и каталоги с правами root или попытаться изменить их, если у вас нет таких разрешений.

При этом как только вам нужно изменить файл, созданный sudo npm install, вы должны использовать привилегии, чтобы либо изменить его разрешения, либо полностью удалить его.

Самое простое решение - выполнить sudo rm -rf node_modules для любого проекта, в котором вы сейчас находитесь. Точно так же вам, возможно, придется сделать что-то вроде sudo rm -rf $(npm prefix -g)/{bin,lib/node_modules}, если вы глобально установили модули узлов с неправильным префиксом. Просто имейте в виду, что это удалит библиотеки, которые вы установили с sudo ранее, поэтому вам придется установить их снова. Правильный путь. Считайте это своим возмездием.

В частности, обратите внимание на результат. Прочтите, что вам говорит npm, и найдите каталог, в котором конкретно возникла проблема. Убери это. Если вы не можете удалить его, вам придется использовать sudo rm.

В конечном итоге вы сможете выполнять npm install или npm install -g без использования sudo.

Однако иногда вы можете столкнуться с другими, не связанными с этим проблемами (попробуйте npm install oracledb!)

Знайте, что вы делаете с sudo

Я понимаю, что многие разработчики усвоили урок

Если что-то не работает, попробуйте еще раз с sudo.

Это напоминает мне похожее обстоятельство: если kill не убивает процесс, используйте kill -9. Я думаю, что вы могли бы спросить у многих разработчиков, какие сигналы kill и kill -9 отправляются процессам, и многие из них в ответ смотрели бы пустым взглядом (SIGTERM И SIGKILL).

Точно так же использование sudo - не ответ на все вопросы. Есть причина, по которой root называется привилегированным пользователем. Вы зарабатываете привилегии, выполняя ответственность, и главная из этих обязанностей - знать, что команда будет делать, когда вы ее действительно запускаете.

Если вы точно не знаете, что будет делать команда, прежде чем запускать ее с sudo (или вас не волнует, что вы испортите систему), спросите кого-нибудь. sudo - это то, что следует использовать с осторожностью, а не с разочарованием. В этом отношении знайте, что visudo и sudoedit тоже существуют!

Однако, если вы уберете что-нибудь из этого сообщения, это должно быть так, что вам никогда не нужно делать sudo npm ни для чего.

Кстати, это произносится как «сью ду».

Первоначально опубликовано на сайте blog.explosion-pills.com 9 апреля 2015 г.