Руководство по Node.js, часть 5: npm и npx
Сегодня, в пятой части перевода руководства по Node.js, мы завершим разбор возможностей npm, в частности, коснёмся таких вопросов, как выяснение установленных версий npm-пакетов, установка старых версий пакетов, обновление зависимостей, локальная и глобальная деинсталляция пакетов. Здесь же мы поговорим и об npx.
Выяснение версий установленных npm-пакетов
Для того чтобы узнать версии всех установленных в папке проекта npm-пакетов, включая их зависимости, выполните следующую команду:
В результате, например, может получиться следующее:
То же самое можно узнать и просмотрев файл package-lock.json проекта, но древовидную структуру, которую выводит вышеописанная команда, удобнее просматривать.
Для того чтобы получить подобный список пакетов, установленных глобально, можно воспользоваться следующей командой:
Вывести только сведения о локальных пакетах верхнего уровня (то есть, тех, которые вы устанавливали самостоятельно и которые перечислены в package.json ) можно так:
В результате, если, например, устанавливали вы только пакет cowsay, выведено будет следующее:
Для того чтобы узнать версию конкретного пакета, воспользуйтесь следующей командой:
В результате её выполнения получится примерно следующее:
Эта команда подходит и для выяснения версий зависимостей установленных вами пакетов. При этом в качестве имени пакета, передаваемого ей, выступает имя пакета-зависимости, а вывод команды будет выглядеть следующим образом:
Запись о пакете-зависимости в этой структуре будет выделена.
Если вы хотите узнать о том, каков номер самой свежей версии некоего пакета, доступного в npm-репозитории, вам понадобится команда следующего вида:
В ответ она выдаёт номер версии пакета:
Установка старых версий npm-пакетов
Установка старой версии npm-пакета может понадобиться для решения проблем совместимости. Установить нужную версию пакета из npm можно, воспользовавшись следующей конструкцией:
В случае с используемым нами в качестве примера пакетом cowsay, команда npm install cowsay установит его самую свежую версию (1.3.1 на момент написания этого материала). Если же надо установить его версию 1.2.0, воспользуемся такой командой:
Указывать версии можно и устанавливая глобальные пакеты:
Если вам понадобится узнать о том, какие версии некоего пакета имеются в npm, сделать это можно с помощью такой конструкции:
Вот пример результата её работы:
Обновление зависимостей проекта до их самых свежих версий
Кроме того, устанавливая некий пакет, npm находит и устанавливает его зависимости.
В package-lock.json так же будут внесены сведения об этом пакете. Вот его фрагмент:
Для того чтобы узнать, вышли ли новые версии используемых в проекте пакетов, можно воспользоваться следующей командой:
Вот результаты выполнения этой команды для проекта, зависимости которого давно не обновлялись:
Анализ устаревших зависимостей проекта
Для того чтобы обновиться до новых мажорных версий всех используемых пакетов, глобально установите пакет npm-check-updates :
Затем запустите утилиту, предоставляемую им:
Локальная или глобальная деинсталляция пакетов
), выполните команду следующего вида:
При выполнении подобной команды текущая папка значения не имеет.
О выборе между глобальной и локальной установкой пакетов
Когда и почему пакеты лучше всего устанавливать глобально? Для того чтобы ответить на этот вопрос, вспомним о том, чем различаются локальная и глобальная установка пакетов:
.
Подключение локальных и глобальных пакетов в коде осуществляется одинаково:
Итак, какой же способ установки пакетов лучше всего использовать?
В общем случае, все пакеты следует устанавливать локально. Благодаря этому, даже если у вас имеются десятки Node.js-проектов, можно обеспечить, при необходимости, использование ими различных версий одних и тех же пакетов.
Обновление глобального пакета приводит к тому, что все проекты, в которых он применяется, будут использовать его новый релиз. Несложно понять, что это, в плане поддержки проектов, может привести к настоящему кошмару, так как новые релизы некоторых пакетов могут оказаться несовместимыми с их старыми версиями.
Если у каждого проекта имеется собственная локальная версия некоего пакета, даже при том, что подобное может показаться пустой тратой ресурсов, это — очень небольшая плата за возможность избежать негативных последствий, которые могут быть вызваны несовместимостью новых версий пакетов, обновляемых централизованно, с кодом проектов.
Пакеты следует устанавливать глобально в том случае, когда они представляют собой некие утилиты, вызываемые из командной строки, которые используются во множестве проектов.
Подобные пакеты можно устанавливать и локально, запуская предоставляемые ими утилиты командной строки с использованием npx, но некоторые пакеты, всё же, лучше устанавливать глобально. К таким пакетам, которые вам, вполне возможно, знакомы, можно отнести, например, следующие:
О зависимостях проектов
Когда пакет следует рассматривать как обычную зависимость проекта, необходимую для обеспечения его функционирования, а когда — как зависимость разработки?
При установке пакета с помощью команды вида npm install
Зависимости разработки — это пакеты, которые нужны в процессе разработки проекта, в ходе его обычного функционирования они не требуются. К таким пакетам относятся, например инструменты тестирования, Webpack, Babel.
Утилита npx
Сейчас мы поговорим об одной весьма мощной команде, npx, которая появилась в npm 5.2. Одной из её возможностей является запуск исполняемых файлов, входящих в состав npm-пакетов. Мы уже рассматривали использование npx для запуска подобного файла из пакета cowsay. Теперь поговорим об этом подробнее.
▍Использование npx для упрощения запуска локальных команд
Node.js-разработчики опубликовали множество исполняемых файлов (утилит) в виде пакетов, которые предполагалось устанавливать глобально, что обеспечивало удобный доступ к их возможностям, так как запускать их из командной строки можно было, просто введя имя соответствующей команды. Однако работать в такой среде было весьма некомфортно в том случае, если требовалось устанавливать разные версии одних и тех же пакетов.
▍Выполнение утилит без необходимости их установки
В npx имеется ещё одна интереснейшая возможность, благодаря которой утилиты можно запускать без их предварительной установки. Полезно это, в основном, по следующим причинам:
Если же пакет cowsay не будет установлен глобально, подобная команда выдаст ошибку.
Утилита npx позволяет выполнять подобные команды без их установки. Выглядит это, в рамках нашего примера, так:
Такая команда сработает, но, хотя «говорящая» корова, по большому счёту, особой пользы не приносит, тот же самый подход можно использовать и для выполнения куда более полезных команд. Вот несколько примеров:
▍Запуск JavaScript-кода с использованием различных версий Node.js
Это позволяет отказаться от использования инструментов наподобие nvm или других менеджеров версий Node.js.
▍Запуск произвольных фрагментов кода, доступных по некоему адресу
Npx позволяет запускать не только код, опубликованный в npm. В частности, если у вас есть ссылка на некий фрагмент кода (скажем, опубликованного на GitHub gist), запустить его можно так:
Конечно, при выполнении подобного кода нельзя забывать о безопасности. Npx даёт в руки разработчика большие возможности, но они означают и большую ответственность.
▍Итоги
Сегодня мы поговорили о некоторых полезных механизмах npm и об использовании npx. На данном этапе у вас должно сложиться базовое понимание устройства npm и методов работы с этим пакетным менеджером. Если вы хотите более глубоко изучить npm — обратитесь к странице документации проекта и побольше экспериментируйте.
В следующий раз мы обсудим некоторые базовые механизмы Node.js, понимание которых необходимо для успешной разработки приложений для этой платформы.
Уважаемые читатели! Пользуетесь ли вы npx?
npm для простых смертных
Эта статья предназначена для тех, кто не очень дружит с Node.js, но хочет использовать приложения вроде Grunt, Gulp и тому подобные. Процесс работы с этими приложениями подразумевает редактирование файла package.json и использование команд npm, так что понимание принципов работы npm поможет вам справиться с трудностями.
Node.js за 5 минут
Понимание того, что такое Node.js поможет вам лучше разобраться с npm. В двух словах — Node.js это интерпретатор языка JavaScript. Сам по себе Node.js является приложением, которое получает на входе и выполняет его.
Давайте создадим простую программу. Создайте файл helloworld.js и поместите в него следующий код:
Программа просто выведет строку «Hello World» в терминал.
Пакеты в Node.js
Файл package.json
Файл package.json содержит в себе информацию о вашем приложении: название, версия, зависимости и тому подобное. Любая директория, в которой есть этот файл, интерпретируется как Node., даже если вы не собираетесь публиковать его.
Способ использования файла package.json зависит от того, собираетесь ли вы скачивать пакет или публиковать его.
Скачивание пакетов
Если вы хотите скачать пакет вручную, вам необязательно использовать для этого package.json. Вы можете выполнить в терминале команду npm с названием нужного пакета в качестве аргумента команды, и пакет будет автоматически скачан в текущую директорию. Например:
Также для скачивания пакетов вы можете использовать package.json. Создайте в директории вашего проекта файл package.json, и добавьте в него следующий код (мы не указываем название нашего пакета и версию, мы не собираемся его публиковать; мы указываем название и версию пакетов для загрузки):
Публикация пакета
Чтобы опубликовать пакет, вам потребуется собрать все исходные коды и файл package.json в одной директории. В package.json должны быть указаны название, версия и зависимости пакета. Например:
Использование пакета в качестве исполняемого файла
Теперь вы знаете, что такое пакет и как он может зависеть от других пакетов. Также вы узнали, как npm работает с пакетами. Давайте перейдём от теории к практике и установим Grunt.
Установка Grunt с помощью npm
Что такое NodeJS и npm?
Что такое NodeJS?
Наверняка вы уже слышали про NodeJS и возможно использовали его в каких-то тестовых или реальных проектах.
Но зачем использовать Javascript еще где-то, кроме как в браузере?
Дело в том, что язык Javascript служит не только для того, чтобы сделать выпадающие меню и мигание кнопочек, как это было задумано изначально, в далеком 1995 году. Прошло уже больше 20 лет и развитие Javascript не стояло на месте. У языка Javascript появилось очень много возможностей и писать различные скрипты достаточно удобно на современном Javascript, а благодаря менеджеру пакетов npm жизнь frontend и backend разработчиков стала лучше.
Смотрите видео Что такое NodeJS и NPM
Что такое npm?
И если вы разрабатываете проект группой разработчиков, для разворачивания вашего проекта у себя на компьютере, достаточно будет запустить одну команду и все необходимые зависимости, такие как фреймворк Bootstrap, различные библиотеки скачаются в проект автоматически.
С помощью менеджера npm можно добавить в ваш проект огромное количество всевозможных библиотек и инструментов и в следующих уроках я покажу как установить NodeJS и пользоваться менеджером пакетов npm, а также покажу как создаются современные frontend приложения.
Также легко, как подключение Bootstrap к вашему проекту через NPM, вы можете подключить и BabelJS, для того, чтобы у вас была возможность писать код вашего приложения на современном Javascript.
Смотрите все уроки по NodeJS и NPM в курсе Modern Javascript
📦 Что такое npm? Гайд по Node Package Manager для начинающих
Miroslav Kungurov
Программная платформа Node.js появилась в 2009 г., и с тех пор на ней были построены сотни тысяч приложений. Одной из причин успеха стал npm – популярный пакетный менеджер, позволяющий JS-разработчикам быстро делиться пакетами.
На момент написания статьи в npm содержится 1.3 млн пакетов с общим количеством скачиваний 16 млрд.
1. Что такое npm?
npm (Node Package Manager) – дефолтный пакетный менеджер для JavaScript, работающий на Node.js. Менеджер npm состоит из двух частей:
Структуру репозитория npmjs.com можно представить, как центр исполнения заказов, который получает товары (npm-пакеты) от продавцов (авторы пакетов) и распространяет эти товары среди покупателей (пользователи пакетов).
В центре исполнения заказов ( npmjs.com ) в качестве персональных менеджеров для каждого покупателя работает армия вомбатов ( npm CLI ).
Зависимости поставляются следующим образом (Рис. 1).
npm install » data-src=»https://media.proglib.io/posts/2020/07/19/85d0ec896b3ad06d69bc27c49c317612.png» > Рис. 1. Процесс установки пакета через npm install
Процесс размещения пакета выглядит, как показано на Рис. 2.
npm publish » data-src=»https://media.proglib.io/posts/2020/07/19/5e2cd72e42190a38f0f46cf7da1d018d.png» > Рис. 2. Процесс размещения пакета через npm publish
Теперь детально рассмотрим работу вомбатов.
1.1. Файл package.json
package.json можно представить, как стикеры (список пакетов нужных версий) на npm-коробке (проект). Файл генерируется командой npm init при создании JavaScript/Node.js проекта со следующими метаданными:
1.2. Скрипты npm
В package.json включено поле scripts для автоматизации сборки, например:
1.3. dependencies и devDependencies
dependencies и devdependencies представляют собой словари с именами npm-библиотек (ключ) и их семантические версии (значение). Пример из шаблона TypeScript Action :
1.4. Файл package-lock.json
Файл package-lock.json описывает версии пакетов, используемые в JavaScript-проекте. Если package.json включает общее описание зависимостей (название товара), то package-lock.json более детальный – всё дерево зависимостей.
2. Установка пакетов
Так как пользователи чаще скачивают пакеты (16 млрд скачиваний против 13 млн публикаций), хорошо бы разобраться, как их устанавливать.
2.1. npm install
npm install – команда, устанавливающая пакеты.
По умолчанию npm install
npm сделал установку пакетов JavaScript настолько простой, что команда часто используется некорректно и в сообществе разрабов появились мемы на эту тему:
Рис. 3. Мем про node_modules
2.2. npm ci
2.3. npm audit
Пример аудита для пакета static-eval
Если исправления доступны в следующих версиях пакета, npm audit fix автоматически обновит версии затронутых зависимостей.
3. Размещение пакетов
Перейдем от потребления пакетов к их размещению.
3.1. npm publish
Еще более важно следовать вышеуказанным правилам при публикации собственных пакетов, чтобы гарантировать, что вы не нарушаете чью-либо совместимость, так как по умолчанию в npm берется версия ^ (следующая младшая версия).
Заключение
В этой публикации мы познакомились со структурой npm и узнали:
Если самостоятельная работа с npm-пакетами вызывает трудности, и вам требуется помощь наставника, мы советуем обратить внимание на курс факультета Веб-разработки GeekBrains, где вы получите готовую базу навыков и необходимую поддержку. Вы не только освоите работу с Node.js, но и научитесь целиком разрабатывать безопасные веб-приложения.
Курс поможет освоить профессию веб-разработчика, получить диплом и создать портфолио с рабочими проектами. В случае успешного прохождения команда университета поможет с трудоустройством. Ознакомиться с программой и отзывами можно, нажав расположенную ниже кнопку.
Использование модулей Node.js с npm и package.json
Published on April 13, 2020
Автор выбрал фонд Open Internet/Free Speech для получения пожертвования в рамках программы Write for DOnations.
Введение
Благодаря таким функциям, как оперативное выполнение ввода/вывода и его широко известному синтаксису JavaScript, Node.js быстро стал популярной рабочей средой для разработки веб-приложений на стороне сервера. Но по мере роста интереса создаются более крупные приложения, а управление сложностью базы кода и ее зависимостей становится сложнее. Node.js организует эти сложные процессы с помощью модулей, которые являются любым отдельным файлом JavaScript, содержащим функции или объекты, используемые другими программами или модулями. Группа из одного или нескольких модулей часто называется пакетом, а эти пакеты организованы менеджерами пакетов.
При создании более сложных проектов Node.js управление своими метаданными и зависимостями при помощи файла package.json позволит обеспечить более предсказуемые сборки, поскольку все внешние зависимости одинаковы. Файл будет автоматически отслеживать эту информацию. Хотя вы можете изменять файл напрямую для обновления метаданных вашего проекта, вам будет редко требоваться взаимодействовать с ним напрямую для управления модулями.
Предварительные требования
Для данного обучающего руководства вам потребуется следующее:
Шаг 1 — Создание файла package.json
Начнем это обучающее руководство с проекта в качестве примера — гипотетический модуль локатора Node.js, получающий IP-адрес пользователя и возвращающий страну происхождения. Вы не будете кодировать модуль в этом обучающем руководстве. Однако пакеты, которыми вы управляете, будут актуальны, если вы их разрабатывали.
Использование команды init
Вначале настройте проект, чтобы можно было попрактиковаться в управлении модулями. В своей оболочке создайте новую папку под названием locator :
Затем перейдите в новую папку:
Теперь инициализируйте интерактивную командную строку, введя следующее:
Результат будет выглядеть следующим образом:
Затем команда init запросит репозиторий GitHub проекта. Вы не будете использовать его в данном примере, поэтому оставьте и его пустым.
Шаг 2 — Установка модулей
Обычно в разработке программного обеспечения используются внешние библиотеки для выполнения вспомогательных задач в проектах. Это позволяет разработчику сосредотачивать внимание на бизнес-логике и создавать приложения более быстро и эффективно.
Рассмотрим это на примере. В вашем приложении локатора вы будете использовать библиотеку axios, которая поможет вам выполнять запросы HTTP. Установите ее, введя следующее в оболочке:
После установки библиотеки вы увидите примерно следующее:
Теперь откройте файл package.json в текстовом редакторе по вашему выбору. В этом обучающем руководстве мы будем использовать nano :
Вы увидите новое свойство, как подчеркнуто ниже:
в начале номера версии, это означает, что только более высокие номера версий PATCH удовлетворяют это ограничение.
После завершения просмотра package.json выйдите из файла.
Зависимости разработки
Пакеты, используемые для разработки проекта, но не для его создания или запуска, называются зависимостями разработки. Они не требуются для вашего модуля или приложения в производственной среде, но могут оказаться полезными при написании кода.
Например, разработчики часто используют инструменты статического анализа кода, чтобы обеспечить соответствие кода передовым практикам и единообразие стиля. Хотя это полезно для разработки, это только увеличивает размер дистрибутива без предоставления ощутимых выгод при развертывании в производственной среде.
Установите инструмент статического анализа кода в качестве зависимости разработки для вашего проекта. Попробуйте это в оболочке:
В результате вы получите следующий вывод:
Автоматически сгенерированные файлы: node_modules и package-lock.json
Папка node_modules содержит все установленные зависимости для вашего проекта. В большинстве случаев вы не должны назначать эту папку вашему репозиторию с контролем версии. По мере того как вы будете устанавливать больше зависимостей, размер этой папки будет быстро расти. Кроме того, файл package-lock.json хранит записи точных версий, установленных более сжато, поэтому включение node_modules не требуется.
Установка из package.json
С помощью ваших файлов package.json и package-lock.json вы можете быстро задать те же самые зависимости проекта, прежде чем начать разработку нового проекта. Чтобы продемонстрировать это, перейдите на один уровень выше в дереве директорий и создайте новую папку с именем cloned_locator на том же уровне директории, что и locator :
Перейдите в новую директорию:
Теперь скопируйте файлы package.json и package-lock.json из locator в cloned_locator :
Чтобы установить требуемые модули для этого проекта, введите следующее:
При развертывании в производственную среду вы можете пропустить зависимости разработки. Вспомните, что зависимости разработки хранятся в разделе devDependencies файла package.json и не влияют на управление вашим приложением. При установке модулей в рамках процесса непрерывной интеграции и разработки, чтобы развернуть приложение, пропустите зависимости разработки, введя следующее:
Прежде чем перейти к следующему разделу, вернитесь в папку locator :
Глобальная установка
Проверьте, что пакет успешно установлен, введя следующее:
Вы увидите примерно следующий результат:
Теперь, когда вы можете устанавливать модули, в следующем разделе вы будете практиковать методы управления своими зависимостями.
Шаг 3 — Управление модулями
Полный менеджер пакетов способен на гораздо большее, чем установка модулей. В npm имеется 20 команд, связанных с управлением зависимостями. На этом шаге вы:
Указание модулей
Если вы хотите знать, какие модули установлены в проекте, проще использовать команду list или ls вместо чтения package.json напрямую. Для этого введите следующее:
Результат должен выглядеть следующим образом:
По умолчанию ls отображает все дерево зависимостей — модули, от которых зависит ваш проект, и модули, от которых зависят ваши зависимости. Это может быть довольно неудобно, если вы хотите получить общий обзор того, что установлено.
Чтобы вывести только модули, которые вы установили, без их зависимостей, введите следующее в оболочке:
Результат будет выглядеть следующим образом:
Обновление модулей
Вывод будет выглядеть следующим образом:
Похоже, вы можете обновить eslint до последней версии. Используйте команду update или up следующим образом:
Вывод команды будет содержать установленную версию:
Если хотите обновить все модули одновременно, введите следующее:
Удаление модулей
Удаление зависимостей из проекта — обычное мероприятие в жизненном цикле разработки программного обеспечения. Зависимость может не решить проблему, как заявлено, или может не предоставить удовлетворительный опыт разработки. В этих случаях может быть лучше удалить зависимость и создать собственный модуль.
Вывод будет выглядеть следующим образом:
Здесь не указано явно, что axios был удален. Чтобы убедиться, что он был удален, еще раз укажите зависимости:
Теперь мы видим только то, что установлен eslint :
Проверка модулей
После установки устаревшей версии request вы должны увидеть примерно следующий результат:
npm указывает, что у вас есть уязвимости в ваших зависимостях. Для получения более подробных сведений проверьте весь ваш проект:
Команда audit показывает таблицы вывода, указывающие на недостатки безопасности:
Вы увидите примерно следующий результат:
npm смог безопасно обновить два пакета, тем самым устранив две уязвимости. Но у вас все еще есть четыре уязвимости в ваших зависимостях. Команда audit fix не всегда устраняет каждую проблему. Хотя версия модуля может иметь уязвимость безопасности, если вы обновите ее до версии с другим API, то это может нарушить код выше в дереве зависимостей.
Как упоминалось ранее, это не рекомендуется, если вы не уверены, что это не нарушит функциональность.
