ћерион Ќетворкс

9 минут

Ёта стать€ послужит хорошим руководством по вашему любимому верному спутнику Node.js Ц npm.

Node.js штурмует мир с 2009 года. —отни тыс€ч систем были построены с помощью Node.js, что побудило сообщество разработчиков за€вить, что ЂJavaScript поглощает программное обеспечениеї.

ќдним из составл€ющий успеха Node стал npm Ц его попул€рный диспетчер пакетов, который позвол€ет разработчикам JavaScript быстро и легко обмениватьс€ полезными пакетами, такими как lodash и moment.

Ќа момент написани€ этой статьи npm поспособствовал публикации более 1,3 миллионов пакетов с еженедельной загрузкой более 16 миллиардов! Ёти цифры €вл€ютс€ фантастическими дл€ любого программного инструмента. »так, а теперь давайте поговорим о том, что же такое npm.


„то такое NPM?

NPM, или Node Package Manager, - это диспетчер пакетов дл€ среды выполнени€ JavaScript Node.js.

ќн также известен как УNinja Pumpkin Mutants", "Nonprofit Pizza Makers", а также множество других случайных имен, с которыми вы можете поэкспериментировать и, возможно, внести свой вклад в расширени€ npm.

NPM состоит из двух основных частей:

  • инструмент CLI (command-line interface Ц интерфейс командной строки) дл€ публикации и загрузки пакетов
  • онлайн-репозиторий, в котором размещаютс€ пакеты JavaScript.

ƒл€ более нагл€дного представлени€ можно представить, что репозиторий npmjs.com Ц это распределительный центр, который получает пакеты товаров от продавцов (авторов пакетов npm) и распростран€ет их среди покупателей (пользователей пакетов npm).

ƒл€ того, чтобы облегчить данный процесс, в распределительном центре npmjs.com работает арми€ трудолюбивых вомбатов (CLI), которые назначаютс€ в качестве личных помощников дл€ каждого отдельного клиента npmjs.com. таким образом, пакеты доставл€ютс€ разработчикам JavaScript следующим образом:

ƒоставка

ј процесс публикации пакеты дл€ ваших коллег по JavaScript выгл€дит примерно так:

ѕубликаци€

Ќу и да, вомбаты не насто€щие, если что, а дл€ нагл€дности :)

ƒавайте посмотрим, как же эта арми€ вомбатов помогает разработчикам, которые хот€т использовать пакеты JavaScript в своих проектах. ћы также будем наблюдать то, как они помогают мастерам по открытом исходному коду выпускать свои потр€сающие библиотеки в свет.


package.json

 аждый проект в JavaScript Ц будь то Node.js или приложение браузера Ц может рассматриватьс€ как пакет npm с собственной информацией о пакете и функци€ми package.json дл€ описани€ проекта.

ћожно представить, что package.json Ц это этикетки на коробках с npm, которые доставл€ет ваша арми€ вомбатов.

package.json создаетс€ при запуске npm init дл€ инициализации проекта JavaScript/Node.js со следующими основными метаданными, предоставленными разработчиками:

  • name: им€ вашей библиотеки/проекта JavaScript.
  • version: верси€ вашего проекта. „асто при разработке приложений этим полем пренебрегают, так как нет очевидной необходимости в управлении верси€ми библиотек с открытым исходным кодом. Ќо тем не менее, эта информаци€ может пригодитьс€ в качестве источника версии развертывани€.
  • description: описание проекта.
  • license: лицензи€ на проект.

npm-скрипты

package.json также поддерживает scripts (скрипты), которые можно определить дл€ запуска инструментов командной строки, установленных в локальном контексте проекта. Ќапример, скрипты проекта npm могут выгл€деть примерно так:

{
  "scripts": {
    "build": "tsc",
    "format": "prettier --write **/*.ts",
    "format-check": "prettier --check **/*.ts",
    "lint": "eslint src/**/*.ts",
    "pack": "ncc build",
    "test": "jest",
    "all": "npm run build && npm run format && npm run lint && npm run pack && npm test"
  }
}  

ѕри этом eslint, prettier, ncc, jest не об€зательно должны быть установлены как глобальные исполн€емые файлы, а скорее даже как локальные дл€ вашего проекта внутри node_modules/.bin/.

Ќедавнее введение npx позвол€ет запускать эти команды в области видимости проекта node_modules точно так же, как глобально установленную программу, просто добавив префикс npx ... (то есть npx prettier --write **/*.ts).

dependencies VS devDependencies

Ёти двое представл€ют собой объекты типа Ђключ-значениеї, где ключ Ц это имена библиотек npm, а значение Ц это их версии в семантическом формате. Ќиже представлен пример шаблона действи€ TypeScript на GitHub:

{
  "dependencies": {
    "@actions/core": "^1.2.3",
    "@actions/github": "^2.1.1"
  },
  "devDependencies": {
    "@types/jest": "^25.1.4",
    "@types/node": "^13.9.0",
    "@typescript-eslint/parser": "^2.22.0",
    "@zeit/ncc": "^0.21.1",
    "eslint": "^6.8.0",
    "eslint-plugin-github": "^3.4.1",
    "eslint-plugin-jest": "^23.8.2",
    "jest": "^25.1.0",
    "jest-circus": "^25.1.0",
    "js-yaml": "^3.13.1",
    "prettier": "^1.19.1",
    "ts-jest": "^25.2.1",
    "typescript": "^3.8.3"
  }
}  

Ёти пакеты, от которых зависит приложение, (dependencies) устанавливаютс€ с помощью команды npm install с флагами --save и --save-dev. ќни предназначены дл€ использовани€ в эксплуатационной среде и среде разработки/тестировани€ соответственно. ¬ следующем разделе мы рассмотрим подробнее, как установить эти пакеты.

ћежду тем, важно понимать, что означают знаки, которые могут сто€ть перед семантической версией (при условии, что вы ознакомились с моделью semver major.minor.patch):

  • ^: последний второстепенный выпуск. Ќапример, спецификаци€ ^1.0.4 может установить версию 1.3.0, если это последн€€ дополнительна€ верси€ основной серии 1.
  • ~: последний выпуск исправлени€. јналогично ^ дл€ второстепенных выпусков Ц спецификаци€ ~1.0.4 может установить версию 1.0.7, если это последн€€ второстепенна€ верси€ во второстепенной серии 1.0.

¬се точные версии пакетов будут задокументированы в созданном файле package-lock.json.

package-lock.json

Ётот файл описывает точные версии пакетов, используемых в проекте JavaScript npm. ≈сли package.json - это обща€ описательна€ этикетка, то package-lock.json - это список ингредиентов.

» точно так же, как мы обычно не читаем список ингредиентов продукта (если только вам совсем нечем себ€ зан€ть или вам действительно нужно знать состав), так и package-lock.json не предназначен дл€ того, чтобы разработчики читали его построчно (если только вы отча€нно не пытаетесь решить проблемы из области Ђкак это работаетї).

package-lock.json обычно создаетс€ с помощью команды npm install, а также считываетс€ нашим инструментом NPM CLI, чтобы обеспечить воспроизведение сред сборки дл€ проекта в помощью npm ci.


 ак эффективно управл€ть NPM в качестве Ђпокупател€ї

”читыва€ тот факт, что было опубликовано 1,3 миллиона пакетов, а загрузок было 16 миллиардов, можно сделать вывод, что большинство пользователей npm используют его именно дл€ загрузки пакетов. ѕоэтому стоит знать, как пользоватьс€ этим мощным инструментом.

npm install

Ёто наиболее часто используема€ команда при разработке приложений JavaScript/Node.js.

ѕо умолчанию команда npm install <им€_пакета> устанавливает последнюю версию пакета со знаком версии ^.  оманда npm install в контексте проекта npm загружает пакеты в папку node_modules проекта в соответствии со спецификаци€ми package.json, обновл€€ версию пакета (и, в свою очередь, повторно создава€ package-lock.json) везде, где это возможно, основыва€сь на соответстви€х версии ^ и ~.

¬ы можете указать глобальный флаг -g, если хотите установить пакет в глобальном контексте Ц вы сможете использовать его в любом месте на вашем компьютере (это обычно используетс€ дл€ пакетов инструментов командной строки, таких как like-server).

npm делает установку пакетов JavaScript настолько простой, что эту команду часто используют неправильно. Ёто приводит к тому, что npm становитс€ предметом огромного количества шуток со стороны программистов, таких как эти:

ћемы

«десь на помощь приходит флаг --production! ¬ предыдущем разделе мы обсудили dependencies и devDependencies, предназначенные дл€ использовани€ в эксплуатационной среде и среде разработки/тестировани€ соответственно. Ётот флаг определ€ет то, как создаютс€ отличительные признаки в node_modules.

ƒобавив этот флаг к команде npm install, мы сможем устанавливать пакеты только из dependencies, тем самым резко уменьша€ размер наших модулей node_modules до необходимого дл€ запуска и работы наших приложений.

npm ci

»так, если команда npm install --production оптимальна дл€ эксплуатационной среды, то существует ли команда, котора€ будет оптимальна€ дл€ моей локальной разработки и настройки тестировани€?

ќтвет: npm ci.

“очно так же, как если package-lock.json еще не существует в проекте, то он генерируетс€ вс€кий раз при вызове команды npm install, npm ci использует этот файл дл€ загрузки точной версии каждого отдельного пакета, от которого зависит проект.

»менно так мы можем убедитьс€ в том, что контекст нашего проекта остаетс€ одинаковым на любом оборудовании, будь то наши ноутбуки, которые мы используем дл€ разработки, или среды сборки CI (Continuous Integration Ц непрерывна€ интеграци€), такие как Github Actions.

npm audit

»з-за огромного количества пакетов, которые были опубликованы и могут быть легко установлены, пакеты npm у€звимы из-за недобросовестных авторов с недобрыми намерени€ми.

ѕонима€, что в экосистеме возникла проблема, организаци€ npm.js предложила ввести команду npm audit. ќна поддерживает список брешей в системе безопасности, с помощью которых разработчики могут провер€ть свои пакеты с помощью этой команды.

npm audit предоставл€ет разработчикам информацию об у€звимост€х и о том, существуют ли версии с исправлени€ми дл€ обновлени€. Ќапример:

npm audit

≈сли исправлени€ доступны в следующих некритических обновлени€х версии, то команду npm audit fix можно использовать дл€ автоматического обновлени€ версий затронутых пакетов.


 ак эффективно управл€ть NPM в качестве Ђпродавцаї

ћы рассмотрели, как использовать инструмент NPM CLI в качестве потребител€, но что насчет его эффективного использовани€ в качестве автора (и, возможно, становлени€ мастером JavaScript по открытому исходному коду?)?

npm publish

ќтправить пакет в распределительный центр npmjs.com очень просто Ц достаточно просто запустить команду npm publish. —ложность заключаетс€ в определении версии пакета, но она не относитс€ к авторам пакетов npm.

ѕрактическое правило согласно semver.org:

  • ќ—Ќќ¬Ќјя (MAJOR) верси€ при внесении несовместимых изменений API;
  • ¬“ќ–ќ—“≈ѕ≈ЌЌјя (MINOR) верси€ при добавлении функциональности и сохранении совместимости;
  • ¬ерси€ »—ѕ–ј¬Ћ≈Ќ»я (PATCH) при исправлении ошибок и сохранении совместимости с предыдущими верси€ми.

Ёто очень важно Ц следовать приведенному выше правилу при публикации ваших пакетов, чтобы не нарушать чей-либо программный код, так как соответствие версий по умолчанию в npm Ц ^ (она же следующа€ второстепенна€ верси€).


—кидки 50% в Merion Academy

¬ыбрать курс