Как установить зависимости npm из package json

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

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

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

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

npm shell autocomplete

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

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

npm completion >> ~/.bashrc source ~/.bashrc

npm completion >> ~/.zshrc source ~/.zshrc

Это добавит в конфигурационный файл shell-а необходимый скрипт. После этого, если вы напишите: npm smth… а затем нажмете [TAB] , то shell автоматически дополнит вашу команду или предложит варианты дополнения.

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

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

Однако я предпочитаю вызывать команду следующим образом: npm init -y , а затем править манифест в редакторе. При таком вызове npm не будет задавать вопросов, а просто сгенерирует минимальный манифест со значениями по умолчанию.

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

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

Используется это следующим образом: npm init , где — это название инициализатора (например: esm или react-app ).

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

Например так можно создать React-приложение используя инициализатор create-react-app: npm init react-app — my-react-app . Два минуса позволяют разделить аргументы CLI, которые передаются в команду npm init от тех, что передаются в сам инициализатор. Особенность инициализатора React, например, в том, что проект будет создан не в текущей директории, а в поддиректории с названием, которое вы укажете при вызове (в примере: my-react-app) .

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

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

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

Пример: npm i lodash .

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

Аналогично можно устанавливать сразу несколько зависимостей одновременно: npm i lodash express passport .

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

-P, —save-prod
установка в dependencies (работает по умолчанию)
-D, —save-dev
установка в devDependencies
-O, —save-optional
установка в optionalDependencies

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

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

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

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

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

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

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

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

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

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

—only=prod[uction]
—only=dev[elopment]

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

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

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

Синтаксис команды выглядит следующим образом: npm ls [] , где это опциональное название пакета, который вы хотите найти в дереве зависимостей.

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

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

Иногда бывает необходимо найти ту или иную транзитивную зависимость в дереве проекта, чтобы понять какие пакеты «тянут» ее, для этого можно передать название пакета в команду: npm ls lodash .

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

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

npm ls --depth=0

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

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

npm ls —dev[elopment]
npm ls —prod[uction]

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

npm ls --json

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

Как мы уже рассмотрели в предыдущем посте в 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 это выглядит следующим образом:

Символ «^» (caret, hat или «крышечка») указывается перед номером версии и имеет специальный смысл в semver. В данном случае это означает, что версия зависимости lodash должна обновляться до максимально доступной, но не выше 5.0.0 , т. е. разрешает patch и minor обновления, но запрещает обновления нарушающие обратную совместимость.

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

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

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

Это гарантирует, что lodash будет установлен в ваш проект именно версии 4.17.17 , ни больше, ни меньше.

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

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

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

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

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

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

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

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

Колонка	Описание
Package	Название пакета
Current	Текущая установленная версия
Wanted	Максимальная версия, которая удовлетворяет диапазону semver прописанному в манифесте проекта
Latest	Версия пакета, которую автор указал в качестве самой свежей (как правило максимально доступная версия пакета)
Location	Место расположения зависимости в дереве

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

npm outdated --depth=10

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

npm outdated --depth=9999

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

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

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

Приведем пример: допустим в вашем проекте указан следующий диапазон версий пакета lodash: ^4.16.4 . Вызов npm update приведет к тому, что пакет будет обновлен до версии 4.17.19 , а манифест будет автоматически изменен чтобы содержать следующий диапазон: ^4.17.19 .

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

npm update --depth=9999

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

npm-check

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

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

npm i -g npm-check

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

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

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

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

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

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

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

Ну и наконец, давайте рассмотрим как мы можем удалять ранее добавленные в проект зависимости. Для этого существует команда npm uninstall или сокращенно: rm , r или un . Чтобы удалить один или несколько пакетов, мы можем вызвать команду следующим образом:

npm rm lodash express

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

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

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

Инициализация проекта:
- npm init
  (интерактивно)
- npm init -y
  (с последующим редактированием в IDE)
- npm install
- npm install …
- npm install -D …
- npm outdated
  (просмотр прямых устаревших зависимостей)
- npm outdated —depth=9999
  (просмотр всех устаревших зависимостей)
- npm update
  (обновление прямых устаревших зависимостей с учетом semver)
- npm update —depth=9999
  (обновление всех устаревших зависимостей с учетом semver)
- npm-check
  (просмотр прямых устаревших зависимостей)
- npm-check -u
  (интерактивное обновление прямых устаревших зависимостей)
- npm rm
Продолжение следует

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

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

Управление пакетами npm в Visual Studio

Область применения:Visual Studio Visual Studio для Mac Visual Studio Code

npm позволяет устанавливать пакеты для приложений Node.js и ASP.NET Core, а также управлять ими. Visual Studio позволяет легко взаимодействовать с npm и использовать команды npm через пользовательский интерфейс или напрямую. Если вы не знакомы с npm и хотите узнать больше, перейдите на страницу документации npm.

Интеграция Visual Studio с npm зависит от типа проекта.
- Проекты на основе CLI (.esproj)
- ASP.NET Core
- Открытие папки (Node.js)
- Node.js
- ASP.NET Core
- Открытие папки (Node.js)
npm ожидает найти папку node_modules и файл package.json в корневом каталоге проекта. Если структура папок вашего приложения отличается, ее можно изменить, чтобы управлять пакетами npm с помощью Visual Studio.

Проект на основе CLI (.esproj)

Начиная с Visual Studio 2022 диспетчер пакетов npm доступен для проектов на основе CLI, поэтому теперь можно скачать модули npm аналогично тому, как вы скачиваете пакеты NuGet для проектов ASP.NET Core. Затем можно изменять и удалять пакеты с помощью package.json.

Чтобы открыть диспетчер пакетов, в Обозревателе решений щелкните правой кнопкой узел npm в своем проекте.

Затем вы можете выполнить поиск пакетов npm, выбрать один из них и установить, выбрав команду Установить пакет.

Проекты Node.js

Для проектов Node.js (.njsproj-файлов) можно выполнять следующие задачи:
- Установка пакетов из обозревателя решений
- Управление установленными пакетами из обозревателя решений
- Использование команды .npm в интерактивном окне Node.js
Эти функции работают вместе и синхронизируются с системой проекта и файлом package.json в проекте.

Необходимые компоненты

Чтобы добавить поддержку NPM в проект, вам потребуется рабочая нагрузка разработки Node.js и установленная среда выполнения Node.js. Подробные инструкции см. в разделе Создание приложения Node.js и Express.

Чтобы включить npm в существующем проекте Node.js, используйте шаблон решения Из существующего кода Node.js или тип проекта Открыть папку (Node.js).

Установка пакетов из Обозреватель решений (Node.js)

Самый простой способ установить пакеты npm в проекты Node.js — через окно установки пакетов npm. Чтобы открыть это окно, щелкните правой кнопкой мыши узел npm в проекте и выберите пункт Установить новые пакеты npm.

В этом окне можно найти пакет, указать параметры и установить пакет.
- Тип зависимости — выберите Стандартный, Разработка или Необязательный. Вариант «Стандартный» означает, что пакет является зависимостью среды выполнения, а вариант «Разработка» указывает, что пакет необходим только во время разработки.
- Добавить в package.json — рекомендуется. Этот настраиваемый параметр является устаревшим.
- Выбранная версия — выберите версию пакета, который вы хотите установить.
- Другие аргументы npm — укажите другие стандартные аргументы npm. Вы можете указать значение версии, например @~0.8 , чтобы установить определенную версию, которая недоступна в списке версий.
Ход установки можно просмотреть в выходных данных npm в окне Вывод. Чтобы открыть окно, выберите Вид>Вывод или нажмите сочетание клавиш CTRL + ALT + O. Это может занять некоторое время.

Если вы хотите найти пакеты с заданной областью, добавьте в начало поискового запроса нужную область, например, введите @types/mocha , чтобы искать файлы определений TypeScript для mocha. Кроме того, при установке определений типов для TypeScript можно указать целевую версию TypeScript, указав версию, например @ts2.6 в поле аргумента npm.

Управление установленными пакетами из обозревателя решений (Node.js)

Пакеты npm отображаются в обозревателе решений. Записи в узле npm повторяют зависимости в файле package.json.

Состояние пакета
- — установлено и указано в package.json
- — установлено, но не указано явным образом в package.json
- — Не установлен, но указан в package.json
Щелкните правой кнопкой мыши узел npm, чтобы выполнить одно из следующих действий:
- Установка новых пакетов NPM Открывает пользовательский интерфейс для установки новых пакетов.
- Установка пакетов NPM Запускает команду NPM install, чтобы установить все пакеты, перечисленные в package.json. (Запускаем npm install .)
- Изменить пакеты npm. Обновляет пакеты до последних версий в соответствии с диапазоном семантического управления версиями (SemVer), указанным в package.json. (Запускается npm update —save .). Диапазоны SemVer обычно задаются с помощью «~» или «^». Дополнительные сведения см. в разделе Конфигурация package.json.
Щелкните правой кнопкой мыши узел пакета или выполните одно из следующих действий:
- Установка пакетов NPM Запускает команду NPM install, чтобы установить версию пакетов, перечисленных в package.json. (Запускаем npm install .)
- Изменить пакеты npm. Обновляет пакеты до последних версий в соответствии с диапазоном SemVer, указанным в package.json. (Запуск npm update —save .) Диапазоны SemVer обычно задаются с помощью «~» или «^».
- Удалить пакеты NPM удалит пакет и удаляет его из package.json (Запускает npm uninstall —save .)
Сведения о решении проблем с пакетами npm см. в разделе устранение неполадок.

Использование команды .npm в интерактивном окне Node.js (Node.js)

Вы также можете использовать команду .npm в интерактивном окне Node.js для выполнения команды npm. Чтобы открыть окно, в Обозревателе решений щелкните проект правой кнопкой мыши и выберите пункт Открыть интерактивное окно Node.js (или нажмите сочетание клавиш CTRL + K, N).

В этом окне вы можете использовать следующие команды для установки пакета:

.npm install azure@4.2.3

По умолчанию npm будет выполняться в домашнем каталоге проекта. Если у вас несколько проектов в решении, укажите имя или путь к проекту в квадратных скобках. .npm [MyProjectNameOrPath] install azure@4.2.3

Если проект не содержит файл package.json, используйте .npm init -y , чтобы создать файл package.json со значениями по умолчанию.

Проекты ASP.NET Core

Поддержку npm можно интегрировать, например, в проекты ASP.NET Core, и использовать npm для установки пакетов.
- Добавление поддержки npm в проект
- Установка пакетов с помощью файла package.json
Для установки клиентских файлов JavaScript и CSS в проектах ASP.NET Core вместо npm можно также использовать диспетчер библиотек или yarn.

Добавление поддержки npm в проект (ASP.NET Core)

Если в проекте еще нет файла package.json, добавьте его, чтобы включить поддержку npm. Добавьте файл package.json в проект.
1. Щелкните решение правой кнопкой мыши и выберите пункт «Управление пакетами NuGet». Найдите npm и выберите «Установить», чтобы установить npm.
2. Чтобы добавить файл package.json, щелкните правой кнопкой мыши проект в Обозревателе решений и выберите Добавить>Новый элемент (или нажмите сочетание клавиш CTL + SHIFT + A). Используя поле поиска, найдите файл npm, выберите Файл конфигурации npm , оставьте имя по умолчанию и нажмите кнопку Добавить.
3. Включите один или несколько пакетов npm в раздел dependencies или devDependencies файла package.json. Например, в файл можно добавить следующие пакеты:
```
"devDependencies": < "gulp": "4.0.2", "@types/jquery": "5.3.1" >
```
При сохранении файла Visual Studio добавляет пакет в узел Зависимости / npm в обозревателе решений. Если узел не отображается, щелкните правой кнопкой мыши файл package.json и выберите пункт Восстановить пакеты.

В некоторых сценариях Обозреватель решений могут не отображать правильное состояние установленных пакетов npm. Дополнительные сведения см. в разделе Устранение неполадок.

Установка пакетов с помощью файла package.json (ASP.NET Core)

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

IntelliSense в package.json помогает выбрать конкретную версию пакета npm.

При сохранении файла Visual Studio добавляет пакет в узел Зависимости / npm в обозревателе решений. Если узел не отображается, щелкните правой кнопкой мыши файл package.json и выберите пункт Восстановить пакеты.

Установка пакета может занять несколько минут. Проверьте ход установки пакета, перейдя к выходным данным npm в окне вывода.

Устранение неполадок при работе с пакетами npm
- Для проектов Node. js необходимо установить рабочую нагрузку разработки Node. js для поддержки npm. Для npm требуется Node.js. Если Node.js не установлен, мы рекомендуем установить версию LTS с веб-сайта Node.js для обеспечения наилучшей совместимости с внешними платформами и библиотеками.
- В некоторых сценариях Обозреватель решений может не отображаться правильное состояние установленных пакетов npm из-за известной проблемы, описанной здесь. Например, пакет может отображаться как не установлен при его установке. В большинстве случаев обозреватель решений можно обновить, удалив файл package.json, перезапустив Visual Studio и повторно добавив файл package.json, как описано выше в этой статье. Или при установке пакетов можно использовать окно вывода npm для проверки состояния установки.
- В некоторых сценариях ASP.NET Core узел npm в Обозреватель решений может не отображаться после сборки проекта. Чтобы снова сделать узел видимым, щелкните правой кнопкой мыши узел проекта и выберите команду Выгрузить проект. Затем щелкните правой кнопкой мыши узел проекта и выберите команду Перезагрузить проект.
- При возникновении ошибок при создании приложения или транскомпиляции кода TypeScript проверьте известные несовместимости пакета NPM, возможно они стали причиной ошибок. Чтобы определить ошибки, проверьте окно вывода npm при установке пакетов, как описано выше в этой статье. Например, если одна или несколько версий пакета npm устарела и приводит к ошибке, может потребоваться установить более последнюю версию для устранения ошибок. Дополнительные сведения об использовании package.json для контроля версий пакетов npm см. в разделе Конфигурация package.json.
Конфигурация package.json

Область применения:Visual Studio Visual Studio для Mac Visual Studio Code

Если вы разрабатываете приложение Node.js с большим количеством пакетов npm, нередко возникают предупреждения или ошибки при выполнении сборки проекта, если один пакет или несколько были обновлены. Иногда это возникает из-за конфликта версий или версия пакета является нерекомендуемой. Вот несколько советов по настройке файла package.json и поиску причин предупреждений или ошибок. Это не полное руководство по package.json. Здесь описывается только управление версиями пакета npm.

Система управления версиями пакета npm имеет строгие правила. Версии имеют следующий формат:
```
[major].[minor].[patch] 
```
Предположим, у вас есть пакет в приложении с версией 5.2.1. Основная версия — 5, дополнительная версия — 2, версия исправления — 1.
- В обновлении основного номера версии пакет включает новые возможности, которые несовместимы с предыдущими версиями, то есть критические изменения.
- В обновлении дополнительного номера версии в пакет добавлены новые возможности, которые несовместимы с более ранними версиями пакета.
- В обновлении исправления включено одно исправление ошибок или несколько. Исправления ошибок всегда имеют обратную совместимость.
Стоит отметить, что некоторые компоненты пакета npm имеют зависимости. К примеру, чтобы использовать новую функцию пакета компилятора TypeScript (ts-loader) с webpack, возможно, придется также обновить пакет npm webpack и пакет webpack-cli.

Чтобы контролировать управление версиями, пакет npm поддерживает несколько нотаций, которые можно использовать в файле package.json. Вы можете использовать эти нотации для управления типом обновлений пакета, которые нужно принять в вашем приложении.

Предположим, вы используете React и должны включить пакеты npm react и react-dom. Существует несколько способов указать эти сведения в файле package.json. Например, вы можете указать точную версию пакета следующим образом.
```
"dependencies": < "react": "16.4.2", "react-dom": "16.4.2", >, 
```
Благодаря предыдущей нотации npm всегда получает указанную версию, 16.4.2.

Чтобы ограничить обновления только исправлениями (исправлениями ошибок), можно использовать специальные нотации. В этом примере:
```
"dependencies": < "react": "~16.4.2", "react-dom": "~16.4.2", >, 
```
вы используете символ тильды (~), чтобы указать пакету npm, что нужно обновлять пакет только исправлениями. Таким образом, npm может обновить react 16.4.2 до 16.4.3 (или 16.4.4, и т. д.), но он не будет принимать обновления основного или дополнительного номера версии. Версия 16.4.2 не будет обновлена до 16.5.0.

Также можно использовать символ вставки (^), чтобы npm мог обновлять дополнительный номер версии.
```
"dependencies": < "react": "^16.4.2", "react-dom": "^16.4.2", >, 
```
Благодаря этой нотации npm может обновить react 16.4.2 до 16.5.0 (или 16.5.1, 16.6.0 и т. д.), но он не будет принимать обновления основного номера версии. Версия 16.4.2 не будет обновлена до 17.0.0.

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

Для Visual Studio файл package-lock.json не добавляется в проект, но его можно найти в папке проекта.

Как установить зависимости npm из package json

Кроме встроенных и кастомных модулей Node.js существует огромный пласт различных библиотек и фреймворков, разнообразных утилит, которые создаются сторонними производителями и которые также можно использовать в проекте, например, express, grunt, gulp и так далее. И они тоже нам доступны в рамках Node.js. Чтобы удобнее было работать со всеми сторонними решениями, они распространяются в виде пакетов. Пакет по сути представляет набор функциональностей.

Для автоматизации установки и обновления пакетов, как правило, применяется система управления пакетами или менеджеры. Непосредственно в Node.js для этой цели используется пакетный менеджер NPM (Node Package Manager). NPM по умолчанию устанавливается вместе с Node.js, поэтому ничего доустанавливать не требуется. Но можно обновить установленную версию до самой последней. Для этого в командной строке/терминале надо запустить следующую команду:
```
npm install npm@latest -g
```
Чтобы узнать текущую версию npm, в командной строке/терминале надо ввести следующую команду:
```
npm -v
```
Для нас менеджер npm важен в том плане, что с его помощью легко управлять пакетами.

Установка пакетов

Для установки пакета через npm применяется команда npm install , после которой указываются пакеты
```
npm install имя_пакета1 имя_пакета2 имя_пакетаN
```
В качестве демонстрации будем устанавливать пакет lodash . Lodash представляет собой библиотеку, которая позволяет манипулировать данными, в частности, массивами. Кому интересно, может подробнее узнать на официальном сайте библиотеки — https://lodash.com/.

Допустим, для проекта где-нибудь в файловой системе определим каталог app и перейдем в терминале/командной строке к папке проекта с помощью команды cd . Затем для установки Lodash в проект введем команду
```
npm install lodash
```
После установки express в папке проекта app появится подпапка node_modules , в которой будут хранится все установленные внешние модули. В частности, в подкаталоге node_modules/lodash будут располагаться файлы библиотеки Lodash.

Кроме того, при установке пакета в папку проекта добавляется файл package.json . После добавления lodash в нашем случае он будет иметь примерно следующий вид:

Файл package.json представляет собой объект-конфигурацию в формате json, где каждое свойство представляет отдельную секцию. Так, здесь определена секция «dependencies», которая хранит установленные пакеты. И здесь мы видим, что у нас установлен пакет «lodash», а версия пакета — «^4.17.21».

Также в проекте создан еще один файл — package-lock.json . Этот файл автоматически генерируется при любых операциях, в которых npm изменяет файл package.json и структуру каталогов/файлов в каталоге node_modules . Данный файл упрощает для npm управление пакетами.

После установке библиотеки lodash мы можем ее использовать. Так, определим в папке проекта файл app.js со следующим кодом:
```
const lodash = require("lodash") const people = ["Tom", "Sam", "Bob"]; const employees = ["Tom", "Alice", "Sam"]; // объединение массивов - в результате только уникальные значения const result1 = lodash.union(people, employees); console.log(result1); // [ "Tom", "Sam", "Bob", "Alice" ] // пересечение массивов - в результате только общие значения const result2 = lodash.intersection(people, employees); console.log(result2); // [ "Tom", "Sam" ]
```
Поскольку мы установили библиотеку lodash через npm, то мы можем получить соответствующий модуль через выражение require :
```
const lodash = require("lodash")
```
Затем мы можем обращаться к функциям этого модуля. Для демонстрации здесь применяется функция uninon , которая объединяет два массива (множества) и возвращает новое множество только с уникальными значениями. А функция intersection() также применяется к массивам, но возвращает множество, которое содержит только общие для всех массивов элементы.

В консоли запустим файл app.js командой node app.js :
```
c:\app> node app.js [ "Tom", "Sam", "Bob", "Alice" ] [ "Tom", "Sam" ] c:\app>
```
Если через какое-то время нам больше не нужен пакет, его можно удалить командой npm uninstall , которой передаются удаляемые пакеты
```
npm uninstall пакет1 пакет2 пакетN
```
Например, удалим ранее установленный lodash:
```
npm uninstall lodash
```
Если после удаления мы откроем папку node_modules , то увидим, что она пустая. И также изменится файл package.json — он будет содержать пустой объект:

Получение информации о пакете

С помощью команды npm info [пакет] можно получить информацию об определенном пакете. Например, получим информацию о пакете lodash:
```
c:\app> npm info lodash lodash@4.17.21 | MIT | deps: none | versions: 114 Lodash modular utilities. https://lodash.com/ keywords: modules, stdlib, util dist .tarball: https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz .shasum: 679591c564c3bffaae8454cf0b3df370c3d6911c .integrity: sha512-v2kDEe57lecTulaDIuNTPy3Ry4gLGJ6Z1O3vE1krgXZNrsQ+LFTGHVxVjcXPs17LhbZVGedAJv8XZ1tvj5FvSg== .unpackedSize: 1.4 MB maintainers: - mathias - jdalton - bnjmnt4n dist-tags: latest: 4.17.21 published over a year ago by bnjmnt4n c:\app>
```
Здесь мы видим большой массив данных типа версии, лицензии, кто поддерживает, кто и когда опубликовал, размер пакета, домашнюю страницу.
Похожие публикации: