npm install d что значит

Вы не знаете npm

Перевод и небольшое творческое переосмысление доклада Ashley Williams(человека из команды разработчиков npm) с конференции JavaScript fwdays’17, которая прошла 22 апреля 2017 года в Киеве, Украина. Целью статьи я не ставил дословно перевести выступление Ashley, для вас будет представлена выжимка основных моментов, а именно – фишки npm, о которых не все знают, но знать о которых полезно каждому. В подвале я оставлю ссылку на страницу выступления на сайте frameworksdays.com, где вы сможете найти видео выступления, презентацию и контакты самой Ashley, если они вам понадобятся.

Команда npm prune docs.npmjs.com/cli/prune удаляет модули, которые вы установили, но не использовали в вашем проекте. Так же она оптимизирует дерево зависимостей, рекомендуется использовать эту команду перед публикацией вашего npm-пакета в репозитории npm.

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

Указать версию/изменение версии вашего проекта можно, использовав команду npm version docs.npmjs.com/cli/version узнать о типах версий npm-пакетов, посмотреть различные возможные версии пакетов, которые вы используете, и узнать больше об именовании версий можно по этой ссылке semver.npmjs.com. Если коротко, то разработчики npm рекомендуют нумеровать версии ваших проектов с 1.0.0. Считается, что если версия ниже, например, 0.1.1 – то это предрелизная версия, ещё не готовая к публикации в системе npm, но, к сожалению, не все разработчики придерживаются этой конвенции именования. Первая цифра в обозначении 1.0.0, обозначает тип major – то есть глобальное обновление проекта. Вторая – minor, не столь глобальные изменения и третья – просто patch.

Команда npm run запускает скрипты, указанные вами в разделе «scripts» файла package.json, к примеру, тесты. А чтобы не забыть применить тесты перед публикацией проекта или коммитом вы можете воспользоваться модулем husky www.npmjs.com/package/husky, который добавляет в соответствующий раздел нужные директивы.

Помимо .npm-init.js вы так же можете создать файл .npmignore. Оформляется он так же, как .gitignore, только в этом файле перечисляются имена тех файлов и подкаталогов, которые не должны попасть в npm-пакет вашего модуля. Прочитать об этом подробнее можно в документации docs.npmjs.com/misc/developers, я лишь добавлю, что в отсутствии файла .npmignore npm использует исключения заданные в файле .gitignore, если вас это не устраивает, просто, создайте пустой .npmignore. Так же есть файлы, исключить которые невозможно, например README или package.json.

Если вы впервые публикуете npm-пакет — присмотритесь к модулю под названием np: www.npmjs.com/package/np. Он поможет вам правильно подготовить проект к публикации. А если вы работаете в команде – директива npm team поможет вам сформировать группу и настроить права доступа на публикации модуля.

Примечание переводчика: Это большая часть речи Ashley, если вам интересно поглядеть всё выступление, то оно доступно тут. Я не стал переводить некоторые вещи, касающиеся того, как удалить проект из системы и прочего, что не втискивается в рамки: «набери вот эту команду» или «установи вот этот модуль и будет тебе счастье».

Источник

Шпаргалка по пакетному менеджеру NPM

Установка npm

Обновление npm

Есть несколько способов чтобы обновить npm. Я предпочитаю:

Поиск пакетов в npm

Подсказка: Можно также использовать search.npmjs.org
Вторая подсказка: Для поиска необходимо знать имя нужного пакета (всё прекрасно ищет по любому слову как в имени пакета, так и в его описании, может неправильно перевёл?)

Просмотр информации о пакете

Локальная установка пакетов

Для демонстрации возьмём пакет http-server.
http-server is a package we’ve written which provides an easy to use wrapper around node’s core http.Server class. This module makes for a good example, since it’s API provides both a CLI binary and a requirable node.js module.
http-server — пакет, который мы написали, предоставляет более простой интерфейс в использовании базового модуля http.Server из node.js. Этот модуль хороший пример использования API как для бинарного CLI, так и для подключаемого модуля node.js.

Так мы установим http-server в нашей рабочей директории.
Вы увидите новую папку в node_modules. Сейчас можете не обращать на это внимание.

Установка пакета в наше приложение

test.js

Обратите внимание, как мы делаем: require(‘http-server’)? Что это за магия? (автор молодец)
http-server не является базовым модулем node.js. Этот пакет мы только что установили из npm. Node.js и npm взаимодействуют и автоматически подключают наши локальные модули из node_modules директории.

Понимание разницы между глобальной и локальной установкой

test.js

теперь запустим наш скрипт

мы получим эту ошибку:

Это вполне логично, мы установили http-server локально в «/mynewapp/», а не в «/anotherapp/».
Есть два решения в этой ситуации:
а) Установить ещё раз пакет, но локально в наше новое приложение

б) Установить пакет глобально

Глобальная установка пакетов

Если вы хотите чтобы пакет был доступен всем приложениям, его нужно установить глобально:

Кроме того, поскольку http-server пакет имеет свой исполняемый файл, то этот файл также будет установлен как исполняемый http-server и доступен в командах.
Теперь вы можете просто запустить команду:

Удаление локально установленного пакета

Удаление глобально установленного пакета

Установка определённой версии пакета

Установка модуля с Github

Важно. В некоторых случаях будут патчи, форки или ветви, которые вы хотите использовать, но которые еще не были опубликованы в npm. К счастью исходные коды для большинства npm модулей также доступна на www.github.com

Теперь наша клонированная версия http-server связана локально.

Связи любых пакетов локально

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

На нашу локальную версию http-server создана «связана» для нашей локальной машины. (связь создаётся как «copy-paste», с начало нужно перейти в нужный катало и сделать «copy», потом перейти в нужный каталог и сделать «paste». Так вот сейчас мы изучили как делается «copy», а ниже будет про «paste» этого модуля)

Связи локальных пакетов для нескольких приложений

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

Мы указываем, что теперь создали связь из http-server в наше новое приложение newapp. Если бы мы не выполнили npm link http-server, то получили бы ошибку об отсутствующем модуле. (а вот наш и «paste» о чём я писал выше, теперь вам должна быть понятна логика создания связей)

Отмена связи между пакетами приложения

(здесь мы просто отменяем наш «paste» для этого приложения)

Отмена связи пакета в системе

(здесь мы отменяем наш «copy» для этого пакета)

Создание нового пакета

(от себя хочу лишь заметить, что создание пакета не такая простая задача в одну команду, подробнее можно почитать в другой статье)

Добавление нового пользователя

Публикация пакета в репозиторий npm

Удаление пакета из репозитория npm

Управление правами доступа к пакетам в репозитории npm

Вы можете задать права доступа других пользователей к опубликованному пакету:

Источник

Установка и обновление зависимостей в JavaScript

И снова привет! В прошлом посте мы начали рассматривать процесс управления зависимостями в JavaScript, разобрали основы: что такое npm-пакет, как выглядит манифест пакета, в каких полях прописываются зависимости и в принципе что такое дерево зависимостей, а также основы семантического версионирования (semver). Если вы пропустили предыдущий пост, то рекомендую начать с него.

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

npm shell autocomplete

В моих постах я буду часто упоминать npm и различные команды с его использованием. Чтобы сделать набор команд в терминале чуточку удобнее, предлагаю установить автодополнения в ваш shell.

Сделать это достаточно легко, достаточно выполнить следующие команды:

Для Bash:

Для Z shell:

Инициализация проекта

Как мы уже успели обсудить, проектом в npm является любая директория в которой находится манифест (файл package.json). Вы можете создать манифест вручную в любом редакторе кода, либо выполнить команду npm init. По умолчанию данная команда задаст вам серию вопросов в интерактивном режиме и сгенерирует простейший манифест в текущей директории на основе ваших ответов.

Использование инициализаторов

Говоря про npm init, нельзя не упомянуть про возможность использования специальных пакетов инициализаторов (npm initializers). Данные пакеты облегчают создание новых проектов генерируя необходимый boilerplate-код.

Вы можете и сами написать свой инициализатор и опубликовать его в registry. Это может быть особенно удобно в корпоративной среде, где существует множество стандартов и соглашений — вы можете оформить их все в виде инициализатора и опубликовать его в закрытом npm registry. Таким образом разработчики внутри компании смогут быстро создавать новые проекты.

Добавление зависимостей в проект

Как мы выяснили ранее, зависимости прописываются в манифесте проекта в полях: dependencies, devDependencies, peerDependencies или optionalDependencies. Чтобы добавить новую зависимость в проект необходимо использовать команду: npm install

или сокращенно: npm i

Данная команда установит lodash самой свежей стабильной версии и добавит эту зависимость в поле dependencies манифеста проекта.

Команда install также позволяет выбрать в какое поле будет добавлена зависимость используя флаги:

Если вам нужно установить зависимость в peerDependencies, то придётся сделать это вручную т. к. npm не предусматривает для этого специальной команды. Как вариант, можно сначала установить зависимость в dependencies при помощи команды npm install, а потом перенести ее вручную в peerDependencies, в этом случае вам не придется угадывать свежую версию пакета (если вдруг ваш IDE не поддерживает автоматическую интеграцию с npm).

Конечно, зависимость можно добавить в список и самостоятельно в редакторе кода, но я всегда рекомендую использовать команды npm для добавления зависимостей, т. к. это дает более надежный результат: вы гарантированно получаете последнюю версию нужного пакета и список зависимостей будет корректно отсортирован в лексикографическом порядке (что позволит избежать конфликтов при мерже в Git).

Команда npm install является многоцелевой командой, т. к. одновременно решает сразу несколько задач: установку уже прописанных зависимостей в проект и добавление новых зависимостей с их прописыванием в манифесте.

Добавление зависимости старой версии

Если по какой-то причине вы хотите добавить зависимость не самой свежей версии, то вы можете указать нужную версию через символ «@»:

Однако делать это рекомендуется только в самом крайнем случае. Об этом я расскажу подробнее чуть позже.

Установка зависимостей

Выше мы рассмотрели варианты добавления зависимостей в проект, но как установить зависимости, которые уже прописаны в манифесте, если вы к примеру только сделали git clone?

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

Существует возможность установить только одну категорию зависимостей:

Это может быть полезно, если вы хотите, к примеру, только запустить программу на Node.js, но не работать над ней.

Просмотр установленных зависимостей

Прежде чем мы поговорим про обновление зависимостей было бы полезно научиться просматривать их. Для этой цели в npm также предусмотрена специальная команда: npm ls.

Синтаксис команды выглядит следующим образом: npm ls [

это опциональное название пакета, который вы хотите найти в дереве зависимостей.

Если вызвать команду без аргументов, то она выведет полное дерево зависимостей (не ослепните, дерево может быть огромным):

Крошечная порция результата выдачи команды npm ls в большом проекте.

Результат поиска пакета lodash в дереве зависимостей крупного проекта при помощи команды npm ls lodash.

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

Как вы уже догадались, по умолчанию команда работает со всем деревом целиком.

Также вы можете использовать опции dev или prod для того, чтобы вывести только зависимости из полей dependencies или devDependencies:

Использование же опции json позволяет получить дерево зависимостей в формате пригодном для машинной обработки, в этом режиме npm выводит более подробную информацию о пакетах, а не только название и версию. Данный режим может быть также полезен для отладки и сравнения двух деревьев (например в разных ветках проекта):

Обновление зависимостей

Как мы уже рассмотрели в предыдущем посте в npm для управления зависимостями используется система семантического версионирования (semver). Благодаря ей вы можете обновлять зависимости в своем проекте с предсказуемыми результатами: к примеру, если зависимость обновилась с версии 1.2.3 до версии 1.2.4 (patch update) или 1.3.0 (minor update), то это не сломает ваш проект, т. к. по правилам semver такие обновления не должны нарушать обратной совместимости. А если обновление производится с версии 1.2.3 до версии 2.0.0 или выше, то здесь вам следует обязательно заглянуть в журнал изменений (changelog) данного пакета, чтобы убедиться, что обновление ничего не сломает, возможно вам придется внести изменения в свой код, чтобы восстановить совместимость.

Несмотря на то, что semver гарантирует достаточно высокий уровень безопасности при обновлении, к сожалению, бывают случаи когда разработчики какого-то пакета могут нарушать правила и вносить критические изменения в patch или minor обновлениях (в первую очередь это касается непопулярных пакетов, которыми управляют менее опытные разработчики).

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

Версии зависимостей

Давайте теперь рассмотрим как именно прописываются версии зависимостей в манифесте проекта и какие механизмы дает нам semver для управления процессом обновления. Как я уже упомянул выше, при установке зависимости npm автоматически устанавливает самую свежую версию и включает наиболее свободный режим обновления для данной зависимости: разрешает как patch, так и minor обновления.

В package.json это выглядит следующим образом:

Помимо крышечки существует еще довольно много способов задать диапазон версии, все их можно посмотреть в описании пакета semver, который и реализует данный функционал в npm, однако в 99% случаев зависимости стоит указывать именно через крышечку (как делает npm по умолчанию), т. к. это дает наибольшую гибкость при обновлении зависимостей и в то же время защищает вас от критических изменений.

Фиксация версий зависимостей

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

Однако фиксация версий зависимостей вызывает ряд существенных недостатков:

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

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

Просмотр устаревших зависимостей

Новые версии пакетов регулярно выходят, по этой причине, пакеты, установленные в вашем проекте могут устаревать и их необходимо регулярно обновлять. Команда npm outdated позволяет вам вывести список устаревших пакетов.

Результат команды npm outdated в проекте, где установлены две устаревшие зависимости.

Данная команды выводит таблицу со следующими колонками:

По умолчанию команда npm outdated выводит список прямых зависимостей вашего пакета, однако, если использовать аргумент depth с указанием глубины просмотра, то npm покажет устаревшие зависимости, в том числе и на заданной глубине дерева зависимости:

Чтобы просмотреть полный список всех устаревших зависимостей можно использовать следующую команду:

Обновление устаревших зависимостей

Фактическое обновление устаревших зависимостей в npm производится при помощи команды npm update.

Данная команда проверяет версии установленных зависимостей по отношению к версиям доступным в npm registry учитывая диапазоны версий semver указанных в манифесте вашего проекта. Если установленная версия того или иного пакета в вашем проекте отличается от максимальной версии доступной в registry (учитывая ограничение semver), то более свежая версия будет загружена и установлена, а манифест будет обновлен, чтобы минимальная версия в диапазоне соответствовала установленной. Важно заметить, что весь этот процесс протекает без нарушения semver, т. е. вызов npm update никогда не приведет к нарушению диапазонов версий, указанных в вашем манифесте.

По аналогии с командой npm outdated, команда npm update также поддерживает аргумент depth и по умолчанию обновляет только прямые зависимости проекта, не трогая зависимости в глубине дерева. Поэтому, чтобы обновить все зависимости в проекте необходимо вызывать команду следующим образом:

Это гарантирует что абсолютно все зависимости в дереве (включая транзитивные) будут обновлены до самых последних версий. Такую процедуру рекомендуется делать регулярно, чтобы в вашем проекте всегда был самый свежий код с последними исправлениями багов и проблем безопасности.

npm-check

В качестве альтернативы командам npm outdated и npm update хочу предложить интересный инструмент под названием npm-check.

Вы можете установить его при помощи следующей команды:

Данный инструмент поддерживает интерактивный режим, позволяя вам выбрать галочками те пакеты, которые вы хотите обновить. Кроме того, он позволяет обновлять пакеты не только в рамках ограничений semver, но и игнорируя их, перепрыгивая с одной мажорной версии зависимости на другую. Разумеется делать это нужно осмысленно: тщательно изучая журнал изменений каждого мажорно-обновляемого пакета на наличие нарушений обратной совместимости. И никогда не забывайте тестировать ваш код после любых обновлений!

Результат вызова npm-check в проекте: доступно два обновления, одно мажорное и одно минорное.

Также результат вызова npm-check, но уже в интерактивном режиме: галочками можно выбрать зависимости, которые вы хотите обновить.

В качестве очень полезного бонуса — npm-check позволяет обнаружить, если какая-то из зависимостей не используется в проекте:

npm-check сообщает о том, что пакет lodash возможно не используется в проекте.

Рекомендую всегда держать этот незаменимый инструмент (или аналогичный) в своем арсенале.

Удаление зависимостей

Данная команда удалит указанные пакеты как из файловой системы проекта, так и из его манифеста.

Workflow работы с npm-проектом

На данном этапе мы уже рассмотрели несколько полезных команд и инструментов, давайте попробуем обобщить наши знания для того, чтобы выработать некий workflow для работы над JavaScript-проектами. Не переживайте, потом мы его доработаем, когда углубимся в другие важные вопросы.

Продолжение следует

В данном посте мы более подробно рассмотрели процесс инициализации проекта, добавления, установки и обновления зависимостей. Рассмотрели как semver работает на практике при обновлении зависимостей.

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

Источник

Node.js. Утилиты npm и npx

Утилита npm

Утилита npm — это менеджер пакетов, который входит в состав Node.js. Пакетом называется один или несколько js-файлов, представляющих собой какую-то библиотеку или инструмент. Менеджер пакетов предназначен для скачивания пакетов из облачного сервера, либо для загрузки (публикации) пакетов на этот сервер.

1. Инициализация проекта

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

2. Файл package-lock.json

3. Установленные пакеты

Получить список всех установленных в директории проекта npm-пакетов можно с помощью команды

Получить список всех установленных глобально npm-пакетов (см.ниже) можно с помощью команды

4. Подробная информация о пакете

Посмотреть подробную информацию о пакете, доступного через npm-репозиторий

Получить информацию из npm-репозитория о последней доступной версии пакета

5. Локальная установка пакетов

Установить все пакеты из секций dependencies и devDependencies файла package.json :

Установить все пакеты из секции dependencies файла package.json (для production сервера)

Установить пакет package-name и добавить в секцию devDependencies файла package.json :

Установить пакет package-name и добавить в секцию dependencies файла package.json :

6. Локальное удаление пакетов

Удалить пакет package-name и удалить его из секции devDependencies файла package.json :

Удалить пакет package-name и удалить его из секции dependencies файла package.json :

7. Глобальная установка пакета

По умолчанию npm будет устанавливать все пакеты в локальной директории, в которым мы сейчас работаем (директория проекта). Если нужно, чтобы пакет был доступен всем приложениям, его нужно установить глобально. Но это не лучшее решение — разные проекты могут требовать разные версии одного пакета. Глобально установленный пакет будет нормально работать в одном проекте и вызывать ошибку в другом.

8. Глобальное удаление пакета

Так что если из-за глобально установки пакета возникли трудности — можно удалить его с помощью команды

9. Локальное обновление пакетов

Обновить один пакет или все пакеты проекта (нужно выполнять из директории проекта):

Чтобы узнать, вышли ли новые версии используемых в проекте пакетов

10. Как безопасно обновляться

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

Теперь можно посмотреть, какие пакеты можно обновить (без внесения каких-либо изменений):

Убедившись, что обновление достаточно безопасно, можно выполнять следующую команду:

11. Глобальное обновление пакетов

Обновить один пакет или все пакеты, установленные глобально (можно выполнять из любого места):

12. Установка конкретной версии

Установка старой версии npm-пакета может понадобиться для решения проблем совместимости:

Узнать, какие версии некоего пакета имеются в npm-репозитории

13. Запуск скриптов

Запускать эти команды можно с помощью команды

14. Справка по менеджеру пакетов

У менеджера пакетов есть подробная справка по все командам

Для примера, посмотрим справку по команде install (в браузере)

Утилита npx

Существует множество утилит в виде пакетов (например, create-react-app ), которые изначально предполагалось устанавливать глобально. Запускать их из командной строки было очень просто — достаточно ввести имя утилиты в консоли. Однако мы уже знаем, что глобальная установка пакетов создает множество проблем.

Конечно, мы можем что-нибудь придумать, чтобы избежать проблем с глобальной установкой таких утилит. Например, установить пакет create-react-app глобально, запустить один раз из директории проекта, чтобы создать React-приложение — и сразу после этого удалить.

Если пакет cowsay не установлен глобально, подобная команда выдаст ошибку:

Утилита npx скачает пакет cowsay из npm-репозитория, установит во временную директорию и выполнит утилиту. Что важно — не загрязняя глобальное пространство. Так что при использовании npx необходимости в глобальной установке пакетов больше нет.

Источник