npm история версий пакета
NPM version: версионирование, история изменений, деплой проекта
Как я веду красивую историю изменений в своих проектах и деплою одной командой после коммита (нет, это не git hooks).
Если вы не пишете на JavaScript, пусть вас не смущает слово “NPM”, это подходит для любого языка.
Версионирование
Главная, казалось бы, цель команды: отмечать версии.
Из коробки это значит, что вы можете написать npm version и запустить цепочку задач по подготовке новой версии. Варианта собственно три:
Но можно и принудительно версию вписать, но только по semver.
Что произойдёт:
Минус в том, что создаются коммиты на каждую версию, кого-то это может раздражать, меня наоборот раздражает, что просматривая список коммитов на Github не видно версий, коммиты версий исправляют это.
Как делать теги 1.2.3 вместо v1.2.3 (убрать v из тега версии):
Автоматический Changelog
CHANGELOG.md генерится утилитой conventional-changelog.
Об этом я уже писал 4 года назад. Там я описывал свои поиски, здесь опишу, к чему я пришёл.
С тех пор я все коммиты называю по Angular Conventions. Не пугайтесь “Angular” в названии, никакой привязки там нет.
В 2 словах о соглашениях:
Подробнее, насколько я пользуюсь:
Сообщение имеет структуру:
Я обычно ограничиваюсь:
Типы, в порядке, как я использую:
В футере принято перечислять ссылки на связанные задачи.
CHANGELOG.md при таком конфиге попадёт в коммит версии, что удобно, да и коммиты версий становятся не такими уж бесполезными.
Можно поставить standard-changelog чисто под ангуларовский формат, я по историческим причинам его не использую.
Красивые releases на Github
conventional-github-releaser использует тот же механизм извлечения описания из коммитов, но пишет не в файл, а в релиз на Github.
Вы можете не хотеть автоматом запускать release при версионировании, тогда думаю вы знаете, что делать.
Руководство по 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?
Руководство по 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?
Node.js. Утилиты npm и npx
Утилита npm
Утилита npm — это менеджер пакетов, который входит в состав Node.js. Пакетом называется один или несколько js-файлов, представляющих собой какую-то библиотеку или инструмент. Менеджер пакетов предназначен для скачивания пакетов из облачного сервера, либо для загрузки (публикации) пакетов на этот сервер.
1. Инициализация проекта
Для создания нового проекта нужно создать директорию проекта, перейти в нее и выполнить команду
2. Файл package-lock.json
3. Установленные пакеты
Получить список всех установленных в директории проекта npm-пакетов можно с помощью команды
Получить список всех установленных глобально npm-пакетов (см.ниже) можно с помощью команды
4. Подробная информация о пакете
Посмотреть подробную информацию о пакете, доступного через npm-репозиторий
Получить информацию из npm-репозитория о последней доступной версии пакета
5. Локальная установка пакетов
Установить все пакеты из секций dependencies и devDependencies файла package.json :
Установить все пакеты из секции dependencies файла package.json (для production сервера)
Установить пакет package-name и добавить в секцию devDependencies файла package.json :
Установить пакет package-name и добавить в секцию dependencies файла package.json :
6. Локальное удаление пакетов
Удалить пакет package-name и удалить его из секции devDependencies файла package.json :
Удалить пакет package-name и удалить его из секции dependencies файла package.json :
7. Глобальная установка пакета
По умолчанию npm будет устанавливать все пакеты в локальной директории, в которым мы сейчас работаем (директория проекта). Если нужно, чтобы пакет был доступен всем приложениям, его нужно установить глобально. Но это не лучшее решение — разные проекты могут требовать разные версии одного пакета. Глобально установленный пакет будет нормально работать в одном проекте и вызывать ошибку в другом.
8. Глобальное удаление пакета
Так что если из-за глобально установки пакета возникли трудности — можно удалить его с помощью команды
9. Локальное обновление пакетов
Обновить один пакет или все пакеты проекта (нужно выполнять из директории проекта):
Чтобы узнать, вышли ли новые версии используемых в проекте пакетов
10. Как безопасно обновляться
Для того, чтобы обновиться до новых мажорных версий всех используемых пакетов, нужно глобально установить пакет
Теперь можно посмотреть, какие пакеты можно обновить (без внесения каких-либо изменений):
Убедившись, что обновление достаточно безопасно, можно выполнять следующую команду:
11. Глобальное обновление пакетов
Обновить один пакет или все пакеты, установленные глобально (можно выполнять из любого места):
12. Установка конкретной версии
Установка старой версии npm-пакета может понадобиться для решения проблем совместимости:
Узнать, какие версии некоего пакета имеются в npm-репозитории
13. Запуск скриптов
Запускать эти команды можно с помощью команды
14. Справка по менеджеру пакетов
У менеджера пакетов есть подробная справка по все командам
Для примера, посмотрим справку по команде install (в браузере)
Утилита npx
Существует множество утилит в виде пакетов (например, create-react-app ), которые изначально предполагалось устанавливать глобально. Запускать их из командной строки было очень просто — достаточно ввести имя утилиты в консоли. Однако мы уже знаем, что глобальная установка пакетов создает множество проблем.
Конечно, мы можем что-нибудь придумать, чтобы избежать проблем с глобальной установкой таких утилит. Например, установить пакет create-react-app глобально, запустить один раз из директории проекта, чтобы создать React-приложение — и сразу после этого удалить.
Если пакет cowsay не установлен глобально, подобная команда выдаст ошибку:
Утилита npx скачает пакет cowsay из npm-репозитория, установит во временную директорию и выполнит утилиту. Что важно — не загрязняя глобальное пространство. Так что при использовании npx необходимости в глобальной установке пакетов больше нет.
Поделиться
doctor Brain
мир глазами веб-разработчика
Управление версиями npm
обновляем npm-пакеты, не опасаясь испортить приложение
время чтения 4 мин.
Кроме того, понимание порядка версионирования npm-пакетов, является частым предметом обсуждения при проведении собеседований.
Семантическое управление версиями npm-пакетов объясняет, как управлять зависимостями устанавливаемых npm-пакетов.
Итак, обратимся к основам.
Приступая к созданию нового Nodejs или React проекта, мы запускаем:
Таким образом мы создаем базовый файл package.json, с помощью которого в дальнейшем управляем зависимостями пакетов.
Обычно файл package.json выглядит как-то так:
Видно, что package.json содержит свойство version, значение которого равно 1.0.0 для нового проекта.
Теперь попробуем установить в проект необходимую версию пакета express с помощью команды:
Как результат, в файле package.json будет создан раздел зависимостей:
Так же, можно заметить появление файла package-lock.json, который имеет большое значение и содержит точный номер версии и URL-адрес дистрибутива основного пакета, а так же информацию о зависимых пакетах.
Файл package-lock.json ни при каких условиях нельзя удалять или редактировать, он обновляется автоматически при установке или удалении пакетов.
Семантическое версионирование
Наверное Вы уже обратили внимание на то, что dependencies в файле package.json является объектом, содержащим пары ключ-значение.
Создавая собственный npm-пакет, Вы так же должны следовать указанным выше правилам определения его версии.
Внося в пакет значительные изменения, увеличивайте первую цифру версии проекта на единицу. Внося незначительные изменения, увеличивайте на единицу вторую цифру версии проекта. Если Вы вносите только исправления (патчи), увеличивайте на единицу третью цифру версии.
При определении версии npm-пакета часто используются два символа. Попробуем разобраться, для чего они нужны:
Каретка (ˆ)
ˆ : этот символ означает, что при обновлении пакетов, упомянутых в package.json, с помощью npm update, обновятся только патчи и минорные изменения. Так, если для текущей версии установленного пакета 3.16.1 выйдет новый минорный релиз, он обновится до версии 3.17.1, а если выйдет патч, пакет обновится до последней доступной версии, например, 3.16.3.
Если, Вы хотите, чтобы обновлялась и мажорная версия, используйте синтаксис:
Если нужно установить последнюю доступную версию пакета, запустите команду:
Тильда (˜)
Всегда, можно установить только версии, предоставляемые npm-пакетом (в данном случае речь идет о пакете express).
Нажав на ссылку с указанием количества версий проекта, Вы перейдете к длинному списку доступных версий.
Некоторые полезные команды
Если вы хотите узнать текущие и последние версии всех пакетов из package.json, используйте команду npm outdated
Чтобы получить информацию о всех уязвимых пакетах в проекте и инструкции по устранению выявленных уязвимостей, используйте команду npm audit. Если вы работаете на Mac’е, возможно, потребуется повысить права пользователя с помощью sudo npm audit.
Эта команда покажет список всех уязвимых пакетов, со ссылками на информацию с описанием уязвимостей, степенью угрозы (low, medium, high) и командами, которые нужно выполнить, для устранения потенциальных проблем.
Для обечпения безопасности своих проектов, Вы должны выполнять npm audit один или два раза в месяц и следовать полученным рекомендациям.
Спасибо за внимание.
По материалам статьи Yogesh Chavan “Semantic versioning in npm”.