Управление модулями Node.js с помощью npm и package.json

Благодаря высокой производительности ввода/вывода (I/O), хорошо известному синтаксису JavaScript и другим удобным функциям Node.js быстро стал популярной средой выполнения для веб-разработки бэкенда. Но по мере роста изначально сложного приложения управлять его кодовой базой и ее зависимостями становится все труднее. Node.js решает эту проблему с помощью модулей. Модули – это отдельные файлы JavaScript, содержащие функции или объекты, которые могут использоваться другими программами или модулями. Набор из одного или нескольких модулей обычно называется пакетом, такими пакетами обычно управляют менеджеры пакетов.

npm (или Node.js Package Manager) – это самый популярный стандартный менеджер пакетов в экосистеме Node.js. В основном он используется для установки и управления внешними модулями в проектах, а также для установки широкого спектра инструментов CLI и запуска сценариев. npm отслеживает установленные в проекте модули с помощью файла package.json, который находится в каталоге проекта и содержит:

  • Все необходимые проекту модули и их установленные версии.
  • Все метаданные проекта, такие как автор, лицензия и т.п.
  • Скрипты, которые можно запускать для автоматизации задач в рамках проекта.

По мере усложнения проектов Node.js файл package.json становится особенно важным: он обеспечивает удобное управление метаданными и зависимостями, а также предоставляет вам более предсказуемые сборки, поскольку все внешние зависимости не изменятся. Файл будет автоматически отслеживать всю нужную информацию.

Редактировать этот файл можно и напрямую, но вам редко придется это делать.

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

Требования

Для работы вам понадобится установка Node.js на вашей машине разработки. Здесь мы используем версию 10.17.0. Чтобы установить Node.js на macOS, следуйте мануалу Установка Node.js и настройка локальной среды разработки в macOS. Чтобы установить Node.js в Ubuntu 18.04 с помощью архива PPA, читайте Установка Node.js в Ubuntu 18.04.

Пакетный менеджер npm устанавливается вместе с Node.js; в руководстве мы используем его версию 6.11.3.

1: Создание файла package.json 

Мы начнем нашу работу с создания тестового проекта – вымышленного модуля Node.js по имени locator, который принимает IP-адрес пользователя и возвращает страну происхождения этого адреса. Писать код модуля вам не придется: мы просто примем такой условный контекст, чтобы рассмотреть пакеты, которые были бы актуальны в подобном проекте.

Сначала создайте файл package.json для хранения метаданных о проекте и управления зависимыми модулями проекта Node.js. Как следует из расширения, это файл JSON (JavaScript Object Notation) – это стандартный формат для совместного использования кода, основанный на объектах 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, вам придется добавить эту информацию самостоятельно.

Читайте также:

Вы получите следующий вывод:

This 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)

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

Следующее значение, которое нужно ввести, – это version, версия. Как и name, это поле обязательно нужно заполнить, если ваш проект будет доступен другим пользователям в репозитории пакетов npm.

Примечание: Пакеты Node.js должны соответствовать семантическому управлению версиями (Semantic Versioning, semver). Исходя из этого, первое число в номере версии – это версия MAJOR (оно изменяется только при изменении API). Второе число – версия MINOR (изменяется при добавлении функций). Последнее число в номере версии – версия PATCH (это число изменяется при исправлении ошибок).

Нажмите Enter, чтобы принять номер версии по умолчанию.

Следующее поле – описание, description – полезная строка, объясняющая, что умеет этот модуль Node.js. Наш вымышленный проект locator принимает IP-адрес пользователя и возвращает страну происхождения этого адреса. Потому в поле description можно ввести что-то вроде:

Finds the country of origin of the incoming request

и нажать Enter. Описание очень помогает при поиске модулей.

В следующем запросе команда предложит указать точку входа, entry point. Если кто-то установит ваш модуль и объявит его зависимостью проекта, то значение entry point будет первой частью загруженной программы. Здесь следует указать относительный путь к файлу JavaScript, который будет добавлен в свойство main в package.json. Нажмите Enter, чтобы сохранить значение по умолчанию.

Большинство модулей используют в качестве основной точки входа файл index.js. Это значение по умолчанию свойства main файла package.json, которое является точкой входа для модулей npm. Если у вас нет файла package.json, Node.js по умолчанию попытается загрузить index.js.

Затем вам будет предложено указать test command – это исполняемый скрипт или команда для тестового запуска вашего проекта. Многие популярные модули Node.js тестируются с помощью MochaJestJasmine или других тестовых фреймворков. Тестирование выходит за рамки данной статьи, потому пока что оставьте этот параметр пустым и нажмите Enter, чтобы продолжить.

Потом команда init запросит репозиторий проекта на GitHub. В этом мануале мы не будем использовать его, поэтому также оставьте поле пустым.

После репозитория команда запрашивает ключевые слова, keywords. Это свойство представляет собой массив строк, содержащий полезные термины, которые люди могут использовать для поиска вашего проекта. Лучше всего использовать здесь небольшой набор слов, действительно имеющих отношение к вашему проекту – тогда поиск будет более точным.

Перечислите эти ключевые слова через запятую в виде строки. Для нашего тестового проекта мы используем ip, geo, country. Следовательно, в готовом пакете package.json в массиве keywords будет три элемента.

Следующее поле – author, автор. Оно поможет пользователям вашего модуля связаться с вами в случае необходимости. Например, если кто-то обнаружит в модуле уязвимость, он сможет сообщить вам о проблеме, чтобы вы ее исправили.

Поле author представляет собой строку в следующем формате: “имя \<почта\> (сайт)”. В нашем случае она может выглядеть так: “8host \<8host@your_domain\> (https://your_domain)”. Электронную почту и данные о веб-сайте указывать не обязательно – достаточно просто ввести имя автора. Добавьте контактные данные автора и подтвердите их, нажав Enter.

Теперь вам будет предложено ввести лицензию, license. Эта строка определяет юридические права пользователей и ограничения на использование вашего модуля. Многие модули Node.js имеют открытый исходный код, поэтому npm по умолчанию устанавливает ISC.

На этом этапе вы должны рассмотреть варианты лицензирования и решить, что лучше всего подходит для вашего проекта. Подробные сведения о разных типах открытых лицензий можно найти в этом списке. Если вы не хотите предоставлять лицензию закрытого репозитория, вы можете ввести UNLICENSED. Мы будем использовать здесь стандартную лицензию ISC. Введите ISC в командную строку и нажмите Enter, чтобы завершить процесс создания файла.

Теперь команда init выведет на экран файл package.json, который она собирается создать. Наш файл будет выглядеть примерно так:

About to write to /home/8host/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": "8host <8host@your_domain> (https://your_domain)",

  "license": "ISC"

}

Is this OK? (yes)

Если данные в файле соответствуют вашим ожиданиям, нажмите Enter, чтобы завершить этот процесс и создать файл package.json. С помощью этого файла вы будете вести учет модулей, которые вы устанавливаете для своего проекта.

Теперь, когда у вас есть файл package.json, вы можете попробовать выполнить установку модулей.

2: Установка модулей

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

Например, если нашему условному модулю locator нужно отправить внешний API запрос для получения географических данных, мы могли бы упростить эту задачу с помощью библиотеки HTTP. Поскольку основная цель нашего модуля – сообщить пользователю соответствующие географические данные, мы могли бы также установить пакет, который упростит выполнение HTTP-запросов, и не писать самостоятельно код, который выходит за рамки модуля.

Давайте остановимся на этом примере. В приложении locator мы будем использовать библиотеку axios, которая поможет обрабатывать HTTP-запросы. Установите ее:

npm install axios --save

Команда npm install (вы можете также использовать ее сокращенный вариант, npm i) установит пакет, имя которого вы укажете. Чтобы установить несколько пакетов, укажите их имена через пробел. В данном случае мы устанавливаем только axios. В конце команды можно указать опции, в данном случае мы используем опцию –save, которая указывает, что библиотека axios сохранится как зависимость проекта.

Когда библиотека будет установлена, вы увидите такой вывод:

...

+ axios@0.19.0

added 5 packages from 8 contributors and audited 5 packages in 0.764s

found 0 vulnerabilities

Теперь откройте файл package.json. Здесь мы используем текстовый редактор nano.

nano 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": "8host 8host@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 eslint@6.0.0 --save-dev

Здесь мы использовали флаг –save-dev. Он сохранит eslint как зависимость разработки. Также обратите внимание, что мы добавили @6.0.0 к имени зависимости. Когда модули обновляются, они помечаются версией. Символ @ позволяет npm искать определенный тег устанавливаемого модуля. Без указанного тега npm устанавливает последнюю отмеченную тегом версию. Снова откройте package.json:

nano 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": "8host 8host@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. Вы увидите следующий результат:

node_modules    package.json    package-lock.json

Папка node_modules содержит все установленные зависимости проекта. В большинстве случаев эту папку рекомендуется не включать в репозитории с поддержкой контроля версий. По мере установки новых зависимостей размер этой папки будет быстро расти. Файл package-lock.json хранит записи о точных версиях установленных зависимостей в более сжатой форме, поэтому включение node_modules в репозиторий не требуется.

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

Установка зависимостей из файла package.json 

Благодаря файлам package.json и package-lock.json вы можете быстро установить все общие зависимости проектов, прежде чем начинать разработку нового проекта. Чтобы продемонстрировать, как это работает, мы поднимемся на уровень вверх в дереве каталогов и создадим новую папку по имени cloned_locator на том же уровне каталогов, где хранится наш проект locator:

cd ..

mkdir cloned_locator

Перейдите в новый каталог:

cd cloned_locator

Теперь скопируйте файлы package.json и package-lock.json из локатора в cloned_locator:

cp ../locator/package.json ../locator/package-lock.json .

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

npm i

Менеджер npm проверит наличие файла package-lock.json. Если файл package-lock недоступен, он будет читать зависимости из файла package.json. Обычно установка из package-lock.json выполняется быстрее, поскольку этот файл содержит точные версии модулей и их зависимости и npm не нужно тратить время на поиск подходящей версии для установки.

При развертывании в производстве вы можете пропустить зависимости разработки. Как мы уже говорили, зависимости разработки хранятся в разделе devDependencies файла package.json и не влияют на работу вашего приложения. При установке модулей для развертывания приложения в рамках процесса непрерывной интеграции и доставки опустите зависимости разработки с помощью этого флага:

npm i --production

Флаг –production игнорирует раздел devDependencies во время установки зависимостей. Но пока что они нам еще нужны, потому не используйте этот флаг сейчас.

Перед тем как перейти к следующему разделу, вернитесь в папку проекта locator:

cd ../locator

Глобальная установка зависимостей

Ранее мы устанавливали модули npm только для проекта locator. Но npm также позволяет устанавливать пакеты глобально. Это означает, что пакет будет широко доступен в системе, как и любая другая команда оболочки. Эта возможность полезна для многих модулей Node.js, которые являются инструментами командной строки.

К примеру, мы можем написать о проекте locator в блоге. Для создания статического блога и управления им вы можете использовать библиотеку Hexo. Установите Hexo CLI глобально с помощью команды:

npm i hexo-cli -g

Чтобы установить пакет глобально, мы добавляем к команде флаг -g.

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

sudo npm i hexo-cli -g

Убедитесь, что пакет успешно установлен:

hexo --version

Вы увидите на экране версию пакета:

hexo-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 команд, предназначенных для управления зависимостями. На этом этапе вы узнаете, как:

  • Запрашивать список установленных модулей.
  • Обновлять модули до более свежей версии.
  • Удалять модули, которые вам больше не нужны.
  • Выполнять аудит безопасности модулей, чтобы найти и исправить уязвимости.

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

Список модулей

Если вы хотите узнать, какие модули установлены в проекте, проще использовать команду list (или ls), а не читать package.json. Для этого введите:

npm ls

Вы увидите такой результат:

├─┬ axios@0.19.0

│ ├─┬ follow-redirects@1.5.10

│ │ └─┬ debug@3.1.0

│ │   └── ms@2.0.0

│ └── is-buffer@2.0.3

└─┬ eslint@6.0.0

  ├─┬ @babel/code-frame@7.5.5

  │ └─┬ @babel/highlight@7.5.0

  │   ├── chalk@2.4.2 deduped

  │   ├── esutils@2.0.3 deduped

  │   └── js-tokens@4.0.0

  ├─┬ ajv@6.10.2

  │ ├── fast-deep-equal@2.0.1

  │ ├── fast-json-stable-stringify@2.0.0

  │ ├── json-schema-traverse@0.4.1

  │ └─┬ uri-js@4.2.2

...

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

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

npm ls --depth 0

Параметр –depth позволяет указать, какой уровень дерева зависимостей вы хотите увидеть. Указывая 0, вы получите только зависимости верхнего уровня.

Обновление модулей

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

npm outdated

Вы получите следующий результат:

Package  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. По умолчанию используется уровень 0.

Похоже, наш инструмент eslint пора обновить до более свежей версии. Используйте для этого команду update, или up:

npm up eslint

 Вывод команды сообщит установленную версию:

npm WARN locator@1.0.0 No repository field.

+ eslint@6.7.1

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

Вы получите такой результат:

npm WARN locator@1.0.0 No repository field.

removed 5 packages and audited 176 packages in 1.488s

found 0 vulnerabilities

Как видите, в нем не говорится об удалении axios прямо. Чтобы убедиться, что файл был удален, еще раз запросите список зависимостей:

npm ls --depth 0

Теперь мы видим, что установлен только модуль eslint:

└── eslint@6.7.1

Значит, вы успешно удалили пакет axios.

Аудит модулей

npm предоставляет команду audit, которая позволяет выявить потенциальные риски безопасности в ваших зависимостях. Чтобы увидеть эту команду в действии, установите устаревшую версию модуля request:

npm i request@2.60.0

Когда вы установите устаревшую версию, вы увидите такой результат:

+ request@2.60.0

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 показывает результаты в виде таблицы:

                       === npm audit security report ===

# Run  npm install request@2.88.0  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, как предлагает npm, или же использовать подкоманду fix. Введите:

npm audit fix

Вы увидите такой результат:

+ request@2.88.0

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 обновляет не все модули: версия модуля может иметь уязвимость в системе безопасности, но если audit fix обновит ее до версии с другим API, это может привести к ошибкам в коде на более высоком уровне. В таком случае она не будет выполнять обновление.

Если вы все равно хотите обновить все модули, используйте флаг –force:

npm audit fix --force

Еще раз подчеркнем, что так поступать не рекомендуется, если вы не знаете точно, как это повлияет на код.

Заключение

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

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

А сейчас советуем вам самостоятельно применить на практике те знания, которые вы получили в этом мануале: установите и протестируйте какие-нибудь новые пакеты. Чтобы упростить свою работу, вы также можете ознакомиться с экосистемой JS. Например, можно попробовать TypeScript (расширенный набор JavaScript) или Cordova (этот инструмент превращает веб-сайты в мобильные приложения). Если вы хотите узнать больше о Node.js, читайте другие наши руководства по этой теме.

Tags: , , ,

Добавить комментарий