Введение
Благодаря таким функциям, как оперативное выполнение ввода/вывода и его широко известному синтаксису JavaScript, Node.js быстро стал популярной рабочей средой для разработки веб-приложений на стороне сервера. Но по мере роста интереса создаются более крупные приложения, а управление сложностью базы кода и ее зависимостей становится сложнее. Node.js организует эти сложные процессы с помощью модулей, которые являются любым отдельным файлом JavaScript, содержащим функции или объекты, используемые другими программами или модулями. Группа из одного или нескольких модулей часто называется пакетом, а эти пакеты организованы менеджерами пакетов.
Менеджер пакетов Node.js (npm) — это стандартный и наиболее популярный менеджер пакетов в экосистеме Node.js; он преимущественно используется для установки и управления внешними модулями проекта Node.js. Он также часто используется для установки широкого спектра инструментов командной строки и запуска скриптов проекта. npm отслеживает модули, установленные в проекте с файлом package.json, находящимся в директории проекта и содержащим следующее:
- Все модули, необходимые для проекта, и их установленные версии
- Все метаданные для проекта — например, автор, лицензия и т. п.
- Скрипты, которые можно запустить для автоматизации задач в проекте
При создании более сложных проектов Node.js управление своими метаданными и зависимостями при помощи файла package.json позволит обеспечить более предсказуемые сборки, поскольку все внешние зависимости одинаковы. Файл будет автоматически отслеживать эту информацию. Хотя вы можете изменять файл напрямую для обновления метаданных вашего проекта, вам будет редко требоваться взаимодействовать с ним напрямую для управления модулями.
В этом обучающем руководстве вы будете управлять пакетами с помощью npm. Первый шаг будет состоять в создании и понимании файла package.json. Затем вы сможете использовать его для отслеживания всех модулей, которые вы установили в вашем проекте. В заключение вы укажете зависимости пакетов, обновите пакеты, удалите пакеты и проведете проверку на предмет уязвимостей безопасности.
Шаг 1 — Создание файла package.json
Начнем это обучающее руководство с проекта в качестве примера — гипотетический модуль локатора Node.js, получающий IP-адрес пользователя и возвращающий страну происхождения. Вы не будете кодировать модуль в этом обучающем руководстве. Однако пакеты, которыми вы управляете, будут актуальны, если вы их разрабатывали.
Вначале вы создадите файл package.json, который будет содержать полезные метаданные проекта и поможет вам управлять зависимыми модулями Node.js проекта. Как следует из названия суффикса, это файл JSON (обозначение объектов JavaScript). JSON — стандартный формат, используемый для обмена, основанный на объектах JavaScript и состоящий из данных, сохраненных как пары «ключ-значение». Если хотите узнать больше о JSON, ознакомьтесь с нашей статьей Введение в JSON.
Поскольку файл package.json содержит многочисленные свойства, может быть затруднительно создавать его вручную без копирования и вставки шаблона из другого места. Чтобы упростить процесс, npm предоставляет команду init. Это интерактивная команда, которая задает ряд вопросов и создает файл package.json на основе ваших ответов.
Использование команды init
Вначале настройте проект, чтобы можно было попрактиковаться в управлении модулями. В своей оболочке создайте новую папку под названием locator:
mkdir locator
Затем перейдите в новую папку:
cd locator
Теперь инициализируйте интерактивную командную строку, введя следующее:
npm init
Примечание. Если ваш код будет использовать Git для контроля версий, сначала создайте репозиторий Git, а затем запустите npm init. Команда автоматически понимает, что она находится в папке, управляемой Git. Если задан удаленный Git, он автоматически заполняет следующие поля для вашего файла package.json: repository, bugs и homepage. Если вы инициализировали репозиторий после создания файла package.json, вам нужно будет добавить эту информацию самостоятельно. Дополнительную информацию по контролю версий Git можно найти в нашей серии Введение в Git: установка, использование и ответвления.
Результат будет выглядеть следующим образом:
OutputThis utility will walk you through creating a package.json file. It only covers the most common items, and tries to guess sensible defaults. See `npm help json` for definitive documentation on these fields and exactly what they do. Use `npm install <pkg>` afterwards to install a package and save it as a dependency in the package.json file. Press ^C at any time to quit. package name: (locator)
Сначала вам будет предложено ввести имя нового проекта. По умолчанию команда предполагает, что это имя папки, в которой вы находитесь. Значения по умолчанию для каждого свойства показаны в скобках (). Поскольку в настоящем руководстве будет использоваться значение имени по умолчанию, нажмите ENTER, чтобы принять его.
Следующее значение, которое нужно ввести — версия. Как и в случае с именем, это поле требуется, если ваш проект будет размещаться вместе с другими проектами в репозитории пакетов npm.
Примечание. Пакеты Node.js должны соответствовать руководству по указанию версий Semantic (semver). Поэтому первое число будет номером версии MAJOR, который изменяется только при изменении API. Второе число будет номером версии MINOR, который изменяется при добавлении функций. Последнее число будет номером версии PATCH, который изменяется при исправлении ошибок.
Нажмите ENTER, чтобы принять версию по умолчанию.
Следующее поле описание — полезная строка, чтобы объяснить, что делает ваш модуль Node.js. Наш проект гипотетического локатора получит IP-адрес пользователя и выдаст страну происхождения. Подходящее описание: находит страну происхождения по входящему запросу, поэтому введите нечто подобное и нажмите ENTER. Описание очень полезно, когда люди ищут ваш модуль.
Следующая строка запросит у вас точку входа. Если кто-то осуществляет установку и нуждается в вашем модуле, то указанное вами в точке входа будет первой частью вашей загружаемой программы. Значение должно быть относительным местом расположения файла JavaScript и будет добавлено в свойство main файла package.json. Нажмите ENTER, чтобы сохранить значение по умолчанию.
Примечание. В большинстве модулей файл index.js является основной точкой входа. Это значение по умолчанию для свойства main файла package.json, которое представляет собой точку входа для модулей npm. Если не будет package.json, Node.js попробует загружать index.js по умолчанию.
Далее вам нужно будет ввести команду test, исполняемый скрипт или команду, чтобы запустить тесты проекта. Во многих популярных модулях Node.js тесты написаны и осуществляются с помощью Mocha, Jest, Jasmine или других тестовых структур. Поскольку тестирование выходит за рамки этой статьи, оставьте эту опцию пустой и нажмите ENTER, чтобы продолжить.
Затем команда init запросит репозиторий GitHub проекта. Вы не будете использовать его в данном примере, поэтому оставьте и его пустым.
После строки репозитория команда запросит ключевые слова. Это свойство представляет собой массив строк с полезными терминами, которые можно использовать для поиска репозитория. Лучше всего иметь небольшой набор слов, которые наиболее актуальны для вашего проекта, чтобы обеспечить более целенаправленный поиск. Введите эти ключевые слова как строку с запятыми, разделяющими каждое значение. Для данного проекта, служащего примером, введите ip,geo,country в командной строке. В готовом package.json будет три элемента в массиве для ключевых слов.
Следующее поле в командной строке — автор. Это полезно для пользователей вашего модуля, которые хотят связаться с вами. Например, если кто-то обнаружит средство эксплуатации уязвимостей в вашем модуле, они смогут использовать это поле, чтобы сообщить о проблеме, чтобы вы смогли ее исправить. Поле автор представляет собой строку в следующем формате: "Name \<Email\> (Website)". Например, "Sammy \<sammy@your_domain\> (https://your_domain)" — подходящее значение поля «автор». Электронная почта и веб-сайт являются опциональными данными — подходящее значение поля «автор» может состоять только из имени. Добавьте ваши контактные данные в качестве автора и подтвердите нажатием ENTER.
В заключение вам будет предложено ввести лицензию. Это определяет юридические разрешения и ограничения, которые будут у пользователей при использовании вашего модуля. Многие модули Node.js имеют открытый исходный код, поэтому npm задает значение ISC по умолчанию.
К этому моменту вы должны будете рассмотреть ваши опции лицензирования и определить, что подходит лучше всего для вашего проекта. Дополнительную информацию по различным видам открытых лицензий можно найти в этом списке лицензий от организации Open Source Initiative. Если вы не захотите предоставлять лицензию для частного репозитория, вы можете ввести UNLICENSED в командной строке. Для данного примера используйте лицензию ISC по умолчанию и нажмите ENTER, чтобы завершить этот процесс.
Теперь команда init отобразит файл package.json, который она будет создавать. Он будет выглядеть примерно так:
OutputAbout to write to /home/sammy/locator/package.json:
{
"name": "locator",
"version": "1.0.0",
"description": "Finds the country of origin of the incoming request",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"keywords": [
"ip",
"geo",
"country"
],
"author": "Sammy <sammy@your_domain> (https://your_domain)",
"license": "ISC"
}
Is this OK? (yes)
Когда информация совпадет с тем, что вы видите здесь, нажмите ENTER, чтобы завершить этот процесс и создать файл package.json. С этим файлом вы можете хранить записи о модулях, которые вы установили для вашего проекта.
Теперь, когда у вас есть файл package.json, вы можете протестировать установку модулей на следующем шаге.
Шаг 2 — Установка модулей
Обычно в разработке программного обеспечения используются внешние библиотеки для выполнения вспомогательных задач в проектах. Это позволяет разработчику сосредотачивать внимание на бизнес-логике и создавать приложения более быстро и эффективно.
Например, если наш модуль локатора, используемый в качестве примера, должен сделать внешний запрос API для получения географических данных, мы можем использовать библиотеку HTTP, чтобы упростить эту задачу. Поскольку наша основная цель — предоставление пользователю соответствующих географических данных, мы можем установить пакет, упрощающий для нас запросы HTTP вместо повторной записи этого кода, т. к. это задача, выходящая за рамки нашего проекта.
Рассмотрим это на примере. В вашем приложении локатора вы будете использовать библиотеку axios, которая поможет вам выполнять запросы HTTP. Установите ее, введя следующее в оболочке:
npm install axios --save
Вы начинаете эту команду с npm install — это установит данный пакет (для краткости можно использовать npm i). Затем перечисляете пакеты, которые хотите установить, разделяя их пробелом. В этом случае это axios. В заключение вы заканчиваете команду опциональным параметром --save, который указывает, что axios будет сохранен как зависимость проекта.
После установки библиотеки вы увидите примерно следующее:
Output... + [email protected] added 5 packages from 8 contributors and audited 5 packages in 0.764s found 0 vulnerabilities
Теперь откройте файл package.json в текстовом редакторе по вашему выбору. В этом обучающем руководстве мы будем использовать nano:
nano package.json
Вы увидите новое свойство, как подчеркнуто ниже:
locator/package.json
{
"name": "locator",
"version": "1.0.0",
"description": "Finds the country of origin of the incoming request",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"keywords": [
"ip",
"geo",
"country"
],
"author": "Sammy sammy@your_domain (https://your_domain)",
"license": "ISC",
"dependencies": {
"axios": "^0.19.0"
}
}
Параметр --save указывает npm обновлять package.json с модулем и версиями, которые были только что установлены. Это замечательно, поскольку другие разработчики, работающие над вашим проектами, смогут легко видеть, какие внешние зависимости требуются.
Примечание. Возможно, вы заметили символ ^ перед номером версии для зависимости axios. Вспомните, что семантическое определение версий состоит из трех цифр: MAJOR, MINOR и PATCH. Символ ^ означает, что любая более высокая версия MINOR или PATCH удовлетворит это ограничение версии. Если видите ~ в начале номера версии, это означает, что только более высокие номера версий PATCH удовлетворяют это ограничение.
После завершения просмотра package.json выйдите из файла.
Зависимости разработки
Пакеты, используемые для разработки проекта, но не для его создания или запуска, называются зависимостями разработки. Они не требуются для вашего модуля или приложения в производственной среде, но могут оказаться полезными при написании кода.
Например, разработчики часто используют инструменты статического анализа кода, чтобы обеспечить соответствие кода передовым практикам и единообразие стиля. Хотя это полезно для разработки, это только увеличивает размер дистрибутива без предоставления ощутимых выгод при развертывании в производственной среде.
Установите инструмент статического анализа кода в качестве зависимости разработки для вашего проекта. Попробуйте это в оболочке:
npm i [email protected] --save-dev
В этой команде вы использовали флаг --save-dev. Это сохранит eslint как зависимость, которая необходима только для разработки. Обратите внимание, что вы добавили @6.0.0 к своему имени зависимости. После обновления модулей на них ставится тег версии. @ указывает npm искать конкретный тег модуля, который вы устанавливаете. Без указанного тега npm устанавливает последнюю версию с тегами. Откройте package.json еще раз:
nano package.json
В результате вы получите следующий вывод:
locator/package.json
{
"name": "locator",
"version": "1.0.0",
"description": "Finds the country of origin of the incoming request",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"keywords": [
"ip",
"geo",
"country"
],
"author": "Sammy sammy@your_domain (https://your_domain)",
"license": "ISC",
"dependencies": {
"axios": "^0.19.0"
},
"devDependencies": {
"eslint": "^6.0.0"
}
}
eslint сохранился как devDependencies, вместе с номером версии, который вы указали ранее. Выйдите из package.json.
Автоматически сгенерированные файлы: node_modules и package-lock.json
Когда вы в первый раз устанавливаете пакет в проекте Node.js, npm автоматически создает папку node_modules для хранения модулей, необходимых для вашего проекта, и файл package-lock.json, который вы проверили ранее.
Подтвердите, что они находятся в вашей рабочей директории. В вашей оболочке введите ls и нажмите ENTER. Результат будет выглядеть следующим образом:
Outputnode_modules package.json package-lock.json
Папка node_modules содержит все установленные зависимости для вашего проекта. В большинстве случаев вы не должны назначать эту папку вашему репозиторию с контролем версии. По мере того как вы будете устанавливать больше зависимостей, размер этой папки будет быстро расти. Кроме того, файл package-lock.json хранит записи точных версий, установленных более сжато, поэтому включение node_modules не требуется.
Хотя файл package.json перечисляет зависимости, которые указывают нам на соответствующие версии, которые должны быть установлены для проекта, файл package-lock.json отслеживает все изменения в package.json или node_modules и указывает на конкретную версию установленного пакета. Обычно вы управляете этим в вашем репозитории с контролем версий, а не в node_modules, т. к. это более прозрачное представление всех ваших зависимостей.
Установка из package.json
С помощью ваших файлов package.json и package-lock.json вы можете быстро задать те же самые зависимости проекта, прежде чем начать разработку нового проекта. Чтобы продемонстрировать это, перейдите на один уровень выше в дереве директорий и создайте новую папку с именем cloned_locator на том же уровне директории, что и locator:
cd .. mkdir cloned_locator
Перейдите в новую директорию:
cd cloned_locator
Теперь скопируйте файлы package.json и package-lock.json из locator в cloned_locator:
cp ../locator/package.json ../locator/package-lock.json .
Чтобы установить требуемые модули для этого проекта, введите следующее:
npm i
npm проверит файл package-lock.json, чтобы установить модули. Если файл lock недоступен, он будет читать из файла package.json, чтобы определить установки. Обычно быстрее устанавливать из package-lock.json, поскольку файл lock содержит точные версии модулей и их зависимости, что означает, что npm может не тратить время на нахождение подходящей версии для установки.
При развертывании в производственную среду вы можете пропустить зависимости разработки. Вспомните, что зависимости разработки хранятся в разделе devDependencies файла package.json и не влияют на управление вашим приложением. При установке модулей в рамках процесса непрерывной интеграции и разработки, чтобы развернуть приложение, пропустите зависимости разработки, введя следующее:
npm i --production
Флаг --production игнорирует раздел devDependencies во время установки. Пока что перейдите к вашей сборке разработки.
Прежде чем перейти к следующему разделу, вернитесь в папку locator:
cd ../locator
Глобальная установка
Пока что вы устанавливали модули npm для проекта locator. npm также позволяет устанавливать пакеты на глобальном уровне. Это означает, что пакет доступен вашему пользователю в более широкой системе, как и любая другая команда оболочки. Эта способность полезна для многих модулей Node.js, которые являются инструментами командной строки.
Например, вы хотите завести блог о проекте locator, над которым вы сейчас работаете. Для этого вы можете использовать библиотеку, например Hexo, для создания и управления вашим блогом на статичном веб-сайте. Установите командную строку Hexo на глобальном уровне следующим образом:
npm i hexo-cli -g
Чтобы установить пакет на глобальном уровне, вы добавляете флаг -g к команде.
Примечание. Если вы получите ошибку разрешений, пытаясь выполнить установку этого пакета на глобальном уровне, ваша система может потребовать права суперпользователя для запуска команды. Попробуйте еще раз команду sudo npm i hexo-cli -g.
Проверьте, что пакет успешно установлен, введя следующее:
hexo --version
Вы увидите примерно следующий результат:
Outputhexo-cli: 2.0.0 os: Linux 4.15.0-64-generic linux x64 http_parser: 2.7.1 node: 10.14.0 v8: 7.6.303.29-node.16 uv: 1.31.0 zlib: 1.2.11 ares: 1.15.0 modules: 72 nghttp2: 1.39.2 openssl: 1.1.1c brotli: 1.0.7 napi: 4 llhttp: 1.1.4 icu: 64.2 unicode: 12.1 cldr: 35.1 tz: 2019a
На данный момент вы узнали, как устанавливать модули с помощью npm. Вы можете установить пакеты к проекту локально —либо как зависимость в производственной среде, либо как зависимость разработки. Также вы можете устанавливать пакеты на базе уже существующих файлов package.json или package-lock.json, что позволяет разрабатывать с теми же зависимостями, что и у ваших коллег. В заключение вы можете использовать флаг -g для установки пакетов на глобальном уровне, чтобы получить доступ к ним, независимо от того, находитесь ли вы в проекте Node.js или нет.
Теперь, когда вы можете устанавливать модули, в следующем разделе вы будете практиковать методы управления своими зависимостями.
Шаг 3 — Управление модулями
Полный менеджер пакетов способен на гораздо большее, чем установка модулей. В npm имеется 20 команд, связанных с управлением зависимостями. На этом шаге вы:
- Укажете модули, которые вы установили.
- Обновите модули до последней версии.
- Удалите модули, которые вам больше не нужны.
- Проведете проверку безопасности на ваших модулях, чтобы найти и исправить ошибки безопасности.
Хотя эти примеры будут сделаны в вашей папке locator, все эти команды могут запускаться на глобальном уровне посредством добавления флага -g в конце, как и в случае установки на глобальном уровне.
Указание модулей
Если вы хотите знать, какие модули установлены в проекте, проще использовать команду list или ls вместо чтения package.json напрямую. Для этого введите следующее:
npm ls
Результат должен выглядеть следующим образом:
Output├─┬ [email protected] │ ├─┬ [email protected] │ │ └─┬ [email protected] │ │ └── [email protected] │ └── [email protected] └─┬ [email protected] ├─┬ @babel/[email protected] │ └─┬ @babel/[email protected] │ ├── [email protected] deduped │ ├── [email protected] deduped │ └── [email protected] ├─┬ [email protected] │ ├── [email protected] │ ├── [email protected] │ ├── [email protected] │ └─┬ [email protected] ...
По умолчанию ls отображает все дерево зависимостей — модули, от которых зависит ваш проект, и модули, от которых зависят ваши зависимости. Это может быть довольно неудобно, если вы хотите получить общий обзор того, что установлено.
Чтобы вывести только модули, которые вы установили, без их зависимостей, введите следующее в оболочке:
npm ls --depth 0
Результат будет выглядеть следующим образом:
Output├── [email protected] └── [email protected]
Опция --depth позволяет указать, какой уровень дерева зависимостей вы хотите увидеть. Когда значение 0, вы увидите только зависимости самого высокого уровня.
Обновление модулей
Это хорошая практика, позволяющая поддерживать ваши модули npm обновленными. Это повышает вашу вероятность получения последних исправлений безопасности для модуля. Используйте команду outdated, чтобы проверить, можно ли обновить какие-либо модули:
npm outdated
Вывод будет выглядеть следующим образом:
OutputPackage Current Wanted Latest Location eslint 6.0.0 6.7.1 6.7.1 locator
Сначала эта команда указывает пакет (Package), который установлен, и текущую (Current) версию. В столбце Wanted показано, какая версия удовлетворяет вашему требованию версии в package.json. В столбце Latest показана самая последняя опубликованная версия модуля.
В столбце Location показано, где в дереве зависимостей находится пакет. Команда outdated имеет флаг --depth, как ls. По умолчанию depth равняется 0.
Похоже, вы можете обновить eslint до последней версии. Используйте команду update или up следующим образом:
npm up eslint
Вывод команды будет содержать установленную версию:
Outputnpm WARN [email protected] No repository field. + [email protected] added 7 packages from 3 contributors, removed 5 packages, updated 19 packages, moved 1 package and audited 184 packages in 5.818s found 0 vulnerabilities
Если хотите обновить все модули одновременно, введите следующее:
npm up
Удаление модулей
Команда npm uninstall может удалять модули из ваших проектов. Это означает, что модуль больше не будет установлен в папке node_modules и его нельзя будет увидеть в ваших файлах package.json и package-lock.json.
Удаление зависимостей из проекта — обычное мероприятие в жизненном цикле разработки программного обеспечения. Зависимость может не решить проблему, как заявлено, или может не предоставить удовлетворительный опыт разработки. В этих случаях может быть лучше удалить зависимость и создать собственный модуль.
Представьте, что axios не предоставляет опыт разработки, который вы хотели бы иметь для выполнения запросов HTTP. Удалите axios с помощью команды uninstall или un, введя следующее:
npm un axios
Вывод будет выглядеть следующим образом:
Outputnpm WARN [email protected] No repository field. removed 5 packages and audited 176 packages in 1.488s found 0 vulnerabilities
Здесь не указано явно, что axios был удален. Чтобы убедиться, что он был удален, еще раз укажите зависимости:
npm ls --depth 0
Теперь мы видим только то, что установлен eslint:
Output└── [email protected]
Это показывает, что вы успешно удалили пакет axios.
Проверка модулей
npm предоставляет команду audit, чтобы выявить потенциальные риски безопасности в ваших зависимостях. Чтобы увидеть проверку в действии, установите устаревшую версию модуля request, выполнив следующее:
npm i [email protected]
После установки устаревшей версии request вы должны увидеть примерно следующий результат:
Output+ [email protected] added 54 packages from 49 contributors and audited 243 packages in 7.26s found 6 moderate severity vulnerabilities run `npm audit fix` to fix them, or `npm audit` for details
npm указывает, что у вас есть уязвимости в ваших зависимостях. Для получения более подробных сведений проверьте весь ваш проект:
npm audit
Команда audit показывает таблицы вывода, указывающие на недостатки безопасности:
Output === npm audit security report === # Run npm install [email protected] to resolve 1 vulnerability ┌───────────────┬──────────────────────────────────────────────────────────────┐ │ Moderate │ Memory Exposure │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Package │ tunnel-agent │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Dependency of │ request │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Path │ request > tunnel-agent │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ More info │ https://npmjs.com/advisories/598 │ └───────────────┴──────────────────────────────────────────────────────────────┘ # Run npm update request --depth 1 to resolve 1 vulnerability ┌───────────────┬──────────────────────────────────────────────────────────────┐ │ Moderate │ Remote Memory Exposure │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Package │ request │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Dependency of │ request │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Path │ request │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ More info │ https://npmjs.com/advisories/309 │ └───────────────┴──────────────────────────────────────────────────────────────┘ ...
Вы видите путь к уязвимости, и иногда npm предоставляет способы ее устранения. Вы можете выполнить команду update, как предложено, или выполнить подкоманду fix команды audit. В своей оболочке введите:
npm audit fix
Вы увидите примерно следующий результат:
Output+ [email protected] added 19 packages from 24 contributors, removed 32 packages and updated 12 packages in 6.223s fixed 2 of 6 vulnerabilities in 243 scanned packages 4 vulnerabilities required manual review and could not be updated
npm смог безопасно обновить два пакета, тем самым устранив две уязвимости. Но у вас все еще есть четыре уязвимости в ваших зависимостях. Команда audit fix не всегда устраняет каждую проблему. Хотя версия модуля может иметь уязвимость безопасности, если вы обновите ее до версии с другим API, то это может нарушить код выше в дереве зависимостей.
Вы можете использовать параметр --force, чтобы обеспечить удаление уязвимости:
npm audit fix --force
Как упоминалось ранее, это не рекомендуется, если вы не уверены, что это не нарушит функциональность.
Заключение
В этом обучающем руководстве вы прошли различные упражнения, чтобы продемонстрировать организацию модулей Node.js в пакетах и управление этими пакетами при помощи npm. В проекте Node.js вы использовали пакеты npm как зависимости, создавая и обслуживая файл package.json — запись метаданных вашего проекта, включая модули, которые вы установили. Вы также использовали инструмент командной строки npm для установки, обновления и удаления модулей, помимо указания дерева зависимостей для ваших проектов, а также проверки и обновления модулей, которые устарели.
В будущем использование существующего кода с помощью модулей ускорит время разработки, так как вам не придется дублировать функциональность. Вы также сможете создавать собственные модули npm, и они, в свою очередь, будут управляться другими модулями с помощью команд npm. В качестве дальнейших шагов экспериментируйте с тем, что вы узнали в этом обучающем руководстве, устанавливая и тестируя различные существующие пакеты. Посмотрите, что предоставляет экосистема для упрощения процесса решения проблем. Например, вы можете попробовать TypeScript — расширенную версию JavaScript, или превратить ваш веб-сайт в мобильные приложения с помощью Cordova. Если хотите узнать больше о Node.js, ознакомьтесь с другими нашими обучающими руководствами по Node.js.
