7. Введение в NPM — менеджер пакетов для Node.JS

Всем привет! Эта статья посвящена «NPM». Менеджеру пакетов для Node.JS. Модуль «NPM» идет вместе со стандартной инсталляцией Node.JS. Если вы поставили Node.JS то «NPM» вы поставили тоже. И в этом модуле, кроме всего прочего содержится консольная утилита которая дает доступ к громадной базе данных модулей, поддерживаемых сообществом. Сейчас на главном сайте «NPM» — www.npmjs.com, как они пишут, более четверти миллиона модулей. Это достаточно много, с одной стороны, с другой стороны, это не о чем, поскольку многие модули давно заброшены и не разрабатываются. Но даже если их вычесть, все равно полезных модулей очень много и как правило, если стандартная программистская задача, то модуль для ее решения мы можем найти. Это первое, что вообще надо сделать, поискать готовый модуль.

Сейчас нашей задачей будет понять, что же такое эти самые пакеты с которыми работает «NPM». Для этого мы сейчас познакомимся с программистом, которого зовут Константин. Константин сидит за своим компьютером и только что он создал замечательный модуль. Назвал его «supermodule». Константин хотел бы поделиться этим модулем с другими людьми, конечно же используя «NPM». Для этого Константину не достаточно просто создать директорию с модулем, нужно еще создать для них специальный файл, описание пакета. С названием «package.json». Этот файл содержит самую главную информацию о том, что за пакет здесь находится.

«name : supermodule » как правило «name» совпадает с названием директории и версия здесь самая, что ни на есть первая. Если Константин достаточно ленив, то он может не создавать «package.json» руками а воспользоваться вызовом «npm init» из консоли. «npm init» спросит основные характеристики пакета и их надо будет ввести или пропустить.

Screenshot_7_01

И с генерирует «package.json». Основные поля это

 

Остальные мы с вами посмотрим чуть позже. Наш проект выглядит так

Screenshot_7_021

Итак «package.json» готов и можно опубликовать модуль в центральной базе данных. Для этого существует команда «npm publish» если сейчас ее вызвать то будет ошибка, потому что, чтобы ее опубликовать нужен юзер. По этому Константин набирает «npm adduser» и создает юзера отвечая на появляющиеся поля. NPM отправляет соответствующие запросы и вожделенного юзера Константин получил.

Screenshot_7_03

Теперь вся работа с «NPM» будет от имени этого юзера. Это конечно же имеет значение только если Константин как то работает на изменение в центральной базе данных. Для установки модуля это не нужно, а вот для публикации как раз очень даже важно.

Давайте себе представим, что нас отвлекли и мы отложили публикацию нашего модуля на завтра. Завтра мы возвращаемся в нашу директорию «supermodule» с намерением опубликовать его. Юзера то мы вчера уже создали, нам соответственно надо залогиниться. Очень просто, вводим команду «npm login» далее свой username и password и email.  И вот мы снова здесь. Со списком команд вы можете ознакомится введя команду «npm help».

Возвращаемся к Константину. Вводим «npm publish», он делает запрос к базе данных и отправляет в базу модуль Константина. И что же мы видим

Screenshot_7_04

В чём дело? Почему не работает? Давайте разбираться! Читаем внимательно, говорит, может я не залогинен, хм… Давайте проверим — вводим «npm whoami»

Screenshot_7_05

Всё верно, это я. Ну все ясно, оказывается до нас, некий Илья уже создал модуль с таким названием. Ну конечно же двух модулей с одинаковыми названиями быть не может в одной базе данных «NPM», иначе получилась бы полная неразбериха. Заходим в файл описания пакета, даем новое имя нашему модулю меняя «name : supermodule» на «name : supermodule1234567», пробуем

Screenshot_7_06

 

Ура! Отлично, модуль создан, теперь кто угодно может его поставить, ну а Константин, конечно же если он залогинен, может вносить в него изменения.

А в это время, где то далеко, далеко сидит Петя. Петя пишет проект и в этом проекте ему нужен модуль, который ну просто супер. Петя хочет его найти в базе данных «NPM» и он пишет в консоле «npm search super module» или просто «npm s super module».  «npm search» подтягивает изменения в базе данных в локальный кеш и потом делает поиск. В данном случае в качестве супер модуля вот сколько всего нашлось и конечно нашелся наш модуль «supermodule1234567»

Screenshot_7_07

Петя решил, что хочет поставить именно его. Петя вводит команду «npm install supermodule1234567″ или просто «npm i supermodule1234567». «NPM» скачивает модуль

Screenshot_7_08

Скачивает он его в директорию «node_modules» если ее не существует, то «NPM» её создаёт. В Петином проекте теперь появилась директория «node_modules» и в ней находится супер модуль от Константина. И теперь, конечно, Петя может сделать «require(‘supermodule1234567)»

Screenshot_7_09

И запускаем

Screenshot_7_10

Отлично, вот модуль и пригодился. Обратим внимание на небольшую тонкость, связанную с местом установки модуля. Вернемся в консоль и видите, тут в конце вывода «npm install supermodule1234567» написано куда поставился модуль

Screenshot_7_11

Например Петя сделал директорию «db» и перешел в эту директорию. И захотел поставить какой то модуль в ней. И он вводит «npm install supermodule1234567» и что же произойдет? Модуль поставиться не в ту же директорию из которой Петя вызвал  «npm install»  а в директорию выше, где у нас находится папка «node_modules». Так происходит потому, что модули ставятся по следующему принципу. А именно «NPM» ищет директорию «node_modules» или файл «package.json» в текущей директории, если не находит, ищет на уровень выше, и выше, аж пока не найдет и поставит туда. И вот если не найдет ни директорию «node_modules» ни файл «package.json», только тогда «NPM» сам создаст папку в текущей директории. Смысл в том, что «NPM» таким образом ищет корень пакета, чтоб разместить там нужный нам модуль и как правило именно такое поведение и является желательным.  Ну а что если я все таки хочу поставить модуль в папку «db», очень просто, достаточно «node_modules» руками создать и вызвать находясь в этой директории «npm install».

Со временем Константин выпустит новый модуль. Для того чтобы Пети обновить этот модуль из репозитория, достаточно выполнить команду «npm update» и «npm» обновит все модули находящиеся в директории «node_modules», если их авторы выпустили новые версии. Ну и наконец, если Пете надоело использовать наш супер модуль, он может удалить его из директории «node_modules» руками или использовать команду «npm remove supermodule1234567″ или «npm r supermodule1234567».

Итак мы рассмотрели основной жизненный цикл пакета «NPM».

Основные команды NPM

Жирным выделены короткие варианты команд, можно вводить и так и так.

  • npm init ->  создает package.json
  • npm adduser -> создает пользователя, регистрация своего профиля в NPM
  • npm publish -> публикация пакета в центральной базе данных NPM, ее так же называют репозиторием.
  • npm search -> команда, для поиска пакета.
  • npm install -> поставит модуль по названию.
  • npm update -> обновит модуль по названию, если вызвать без имени модуля, она обновит все модули что есть.
  • npm remove -> удалить модуль по названию.
  • npm help -> позволяет получать встроенный help npm.

Иногда в «npm help» достаточно интересные вещи, например если посмотреть «npm help search» то тебя кидает на локальную доку и тут есть такая информация, что можно искать не просто по ключевым словам, а и по регулярным выражениям.

И на конец, еще одно небольшое дополнение по базе данных по репозиторию. Центральный репозиторий  находится по адресу https://registry.npmjs.org » это база данных в системе CouchDB в которой содержится как раз мета информация про модули. То есть например я захожу «https://registry.npmjs.org/имя_моего_модуля» и здесь содержится информация о модуле, информация из его «package.json» и ссылка на файл с модулем, этот файл тоже находится в базе, он был загружен туда автоматически в процессе выполнения команды «npm publish». Обращаю внимание, все, что загружено в репозиторий является публичным и  открыто для всех. Ну а что если мы работаем в компании которая не может, прямо таки все публиковать открыто и при этом мы хотим использовать «NPM», чтобы внутри компании удобно работать с пакетами? Для этого мы можем поднять свой собственный, корпоративный «NPM» репозиторий и уже работать с ним. На этом мы заканчиваем с общей информацией по «NPM». Дальше мы будем более глубоко изучать «package.json» и пользоваться модулями из этого хранилища.