Как поменять yarn на npm

При создании нового проекта react создает файлы npm при использовании yarn

Такая проблема. При создании нового проекта react использую yarn . Но он создаёт файлы и npm . Как это исправить ?

Отслеживать
задан 12 янв 2021 в 8:14
Itachi Saai Itachi Saai
а что вы имеете ввиду под npm файлами?
12 янв 2021 в 8:16
Создаёт папку node_modules ( при создании через yarn, вроде не должен ее создавать )
12 янв 2021 в 8:26

не, это не относится к npm, npm и yarn это пакетные менеджеры, они формируют node-modules скачивая и устанавливая их для дальнейшего использования, node.js — отдельная программа, она использует node-modules

12 янв 2021 в 8:30
Спасибо за ответ. Думал что не должно быть этих файлов
12 янв 2021 в 8:41

0

Сортировка: Сброс на вариант по умолчанию

Знаете кого-то, кто может ответить? Поделитесь ссылкой на этот вопрос по почте, через Твиттер или Facebook.

• npm
• create-react-app
• yarn

Важное на Мете

Похожие

Подписаться на ленту

Лента вопроса

Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.

Дизайн сайта / логотип © 2024 Stack Exchange Inc; пользовательские материалы лицензированы в соответствии с CC BY-SA . rev 2024.1.8.3130

Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.

Переход с NPM на Yarn — выжимаем пакеты досуха

Разработчик FrontEnd

Оба пакетных менеджера похожи как близнецы-братья, разница заключается в том, что Yarn значительно расширил свой функционал и считается более современной версией NPM. Но как уже подчеркивалось оба инструмента во многом похожи и использовать можно любой на выбор. При желании, переход не займет много времени.

Начнем с файла конфигурации: package.json — он актуален для каждого приложения.
Чтобы подключить Yarn в уже готовом проекте введите команду yarn в результате выполнения команды Yarn изменит инфраструктуру и в директории node_modules вы сможете наблюдать эти изменения.

Когда вы запустите yarn или yarn add , Yarn создаст файл yarn.lock в корневой директории вашего проекта. Не нужно читать или понимать этот файл — просто добавьте его в систему контроля версий. Когда другие люди начнут использовать yarn вместо npm , yarn.lock файл будет гарантией того, что у них будут точно такие же зависимости, как и у Вас.

В большинстве случаев, после выполнения команд yarn или yarn add в первый раз, всё заработает сразу. В некоторых случаях, информация из файла package.json не достаточно точная, чтобы выявить зависимости. Детерминированный способ, которым Yarn выбирает зависимости, выльется в конфликт зависимостей. Обычно это происходит в больших проектах, когда npm install не срабатывает и разработчики часто удаляют директорию node_modules и собирают все заново. Если такое произошло, вначале попробуйте использовать npm , чтобы сделать версии зависимостей более точными, а потом переходите на Yarn.

Другие разработчики в проекте могут продолжать использовать npm , так что не обязательно переходить всем на Yarn в одно и тоже время. Разработчики использующие yarn получат точно такую же конфигурацию, как и у других, а разработчики использующие npm могут получить немного отличающуюся конфигурацию, что является намеренным поведением npm .

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

Если используется файл npm-shrinkwrap.json , есть вероятность получить другой набор зависимостей. Yarn не поддерживает файлы npm shrinkwrap, так как они не обладают достаточной информацией для детерминированного алгоритма Yarn. Если Вы используете эти файлы, то, возможно, самым простым вариантом будет перевести всех разработчиков в проекте одновременно на использование Yarn. Просто удалите существующий файл npm-shrinkwrap.json и проверьте вновь созданный yarn.lock .

Сравнение команд CLI

npm (v5)	Yarn
npm install	yarn install
(Н/Д)	yarn install —flat
(Н/Д)	yarn install —har
npm install —no-package-lock	yarn install —no-lockfile
(Н/Д)	yarn install —pure-lockfile
npm install [package]	yarn add [package]
npm install [package] —save-dev	yarn add [package] —dev
(Н/Д)	yarn add [package] —peer
npm install [package] —save-optional	yarn add [package] —optional
npm install [package] —save-exact	yarn add [package] —exact
(Н/Д)	yarn add [package] —tilde
npm install [package] —global	yarn global add [package]
npm update —global	yarn global upgrade
npm rebuild	yarn install —force
npm uninstall [package]	yarn remove [package]
npm cache clean	yarn cache clean [package]
rm -rf node_modules && npm install	yarn upgrade

�� Начало работы

Parcel — это упаковщик для веб-приложений для разработчиков с различным опытом. Он предлагает великолепную быструю работу с использованием многоядерной обработки и не требует настройки.

Сначала установите Parcel с помощью Yarn или npm:

yarn global add parcel-bundler

npm install -g parcel-bundler

Создайте файл package.json в папке вашего проекта, используя:

yarn init -y

npm init -y

Parcel может принимать любой тип файла в качестве точки входа, но лучше всего использовать файл HTML или JavaScript. Если вы подключили свой основной JavaScript-файл в HTML, используя относительный путь, Parcel также обработает его для вас и заменит ссылку URL-адресом на выходной файл.

Далее создайте файлы index.html и index.js.

html> body> script src="./index.js"> script> body> html>

console.log('Привет, Мир!')

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

parcel index.html

Теперь откройте http://localhost:1234/ в браузере. Если горячая заменя модулей не работает, возможно вам нужно настроить ваш редактор кода. Вы также можете переопределить порт по умолчанию, с помощью опции параметра -p .

Используйте сервер разработки, если у вас нет собственного сервера или ваше приложение полностью отрисовывается на клиенте. Если у вас есть собственный сервер, вы можете запустить Parcel в режиме watch . Этот режим по-прежнему будет автоматически пересобирать приложение при измении файлов и поддерживает горячую замену модулей, но не запускает веб-сервер.

parcel watch index.html

Вы так же можете воспользоваться сервисом createapp.dev чтобы создать Parcel-проект в браузере. Выбирайте компоненты, которые вам нужны, например React, Vue, Typescript или CSS, и вы увидите сгенерированный в реальном времени шаблон проекта. Вы можете использовать этот сервис в качестве примера настройки нового проекта. Или даже загрузить ZIP-архив с готовым шаблоном и сразу начать работу.

Несколько точек входа

В случае, если в вашем приложении более одной точки входа, например index.html и about.html , у вас есть два варианта запуска Parcel:

Указать пути к файлам:

parcel index.html about.html

parcel *.html

Обратите внимание: В случае, если в вашем проекте структура директорий похожа на следующую:

- folder-1 -- index.html - folder-2 -- index.html

То переход к http://localhost:1234/folder-1/ не будет работать. Вместо этого вы должны обращаться точно к html-файлу: http://localhost:1234/folder-1/index.html.

Сборка для продакшена

Когда вы готовы для продакшен-сборки, команда Parcel build не будет отслеживать изменения файлов и просто соберет приложение только один раз. Смотрите подробности в разделе Работа в продакшене.

Добавление Parcel в ваш проект

Бывает, что установить Parcel глобально нет возможности — например, если у вас нет root-доступа к системе или вы используете CI для автоматической сборки вашего проекта. В таком случае вы можете установить и использовать Parcel как локальный пакет.

Чтобы установить с помощью Yarn:

yarn add parcel-bundler --dev

Чтобы установить с помощью NPM:

npm install parcel-bundler --save-dev

Далее, добавьте следующие скрипты в package.json вашего проекта:

< "scripts": < "dev": "parcel ", "build": "parcel build " > >

Теперь вы можете запускать их из консоли:

# Для запуска в режиме разработки yarn dev # or npm run dev # Для запуска продакшен-сборки yarn build # or npm run build

Помогите нам улучшить документацию

Если что-то отсутствует или не совсем понятно, пожалуйста опишите проблему в репозитории сайта или отредактируйте эту страницу .

Сравнение npm, Yarn и pnpm. Какой пакетный менеджер лучше?

На сегодняшний день в области пакетных менеджеров существуют три основных игрока:

1. npm
2. Yarn — Вскоре мы увидим, что Yarn может относиться либо к Yarn Classic(< v2), либо к его более современной версии Yarn Berry.
3. performant npm (pnpm)

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

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

• Обработка и запись метаданные
• Пакетная установка или обновление всех зависимостей
• Добавление, обновление и удаление зависимости
• Запуск скриптов
• Публикация пакетов
• Выполнение аудита безопасности

Однако, несмотря на это равенство, менеджеры пакетов внутренне различаются. Традиционно npm и Yarn устанавливали зависимости в каталог node_modules имеющем плоскую структуру. Но эта стратегия разрешения зависимостей не была лишена критики.

Поэтому, pnpm представил несколько новых концепций для более эффективного хранения зависимостей в каталоге node_modules имеющем вложенную структуру. Yarn Berry идет еще дальше, полностью отказываясь от node_modules в режиме Plug’n’Play (PnP).

В этой статье мы рассмотрим следующие вещи, сравнив варианты реализации, где это нужно:

• Краткая история менеджеров пакетов JavaScript
• Рабочие процессы установки
• Структурп проекта
• Блокировака файлов и хранилище зависимостей
• CLI-команды
• Файлы конфигурации
• Поддержка монорепозиториев
• Производительность и эффективность использования дискового пространства
• Функции безопасности
• Использование в популярных проектах

Не стесняйтесь пропускать и читать то, что наиболее важно для вас.

Как использовать сопутствующий проект

Я создал сопутствующее приложение React, чтобы продемонстрировать некоторые уникальные концепции различных пакетных менеджеров. Для каждого варианта пакетного менеджера существует соответствующая ветка Git. Это проект, который я также использовал для создания таблицы производительности ниже в специальном разделе этого поста.

Хотя тип приложения не важен для темы этой статьи, я выбрал реалистичный проект среднего размера, чтобы иметь возможность осветить различные аспекты; В качестве примера из недавнего прошлого, я взял механизм PnP от Yarn Berry который вызвал бурные дискуссии о проблемах совместимости, данный проект подойдет для освещения этого вопроса.

Краткая история пакетных менеджеров

Самым первым пакетным менеджером, когда-либо выпущенным, был npm, выпущенный еще в январе 2010 года. Он установил основные принципы работы пакетных менеджеров сегодня.

Если npm существует уже более 10 лет, то почему вообще существуют какие-то альтернативы? Вот несколько основных причин, по которым это произошло:

• Различные алгоритмы разрешения зависимостей с различными структурами каталога node_modules (вложенные и плоские, node_modules и режим PnP)
• Различная поддержка hoisting, что имеет последствия для безопасности
• Различные форматы файлов блокировки, каждый из которых влияет на производительность.
• Различные подходы к хранению пакетов на диске, которые влияют на эффективность использования дискового пространства.
• Различная поддержка многопакетных проектов (также называемых рабочими пространствами), что влияет на удобство сопровождения и скорость больших монорепозиториев.
• Различные потребности в новых инструментах и командах, каждая из которых имеет значение для DX. Соответственно, разные потребности в расширяемости с помощью плагинов и инструментов сообщества.
• Различные степени конфигурируемости и гибкости

Давайте углубимся в краткую историю того, как эти потребности были определены после того, как npm стал популярным, как Yarn Classic разрешила некоторые из них, как pnpm расширил эти концепции и как Yarn Berry, как преемник Yarn Classic, пытался сломать шаблон с помощью этих традиционных концепций и процессов.

npm, the pioneer

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

Его выпуск стал революцией, потому что до этого зависимости проекта загружались и управлялись вручную. Такие понятия, как файл package.json с его полями метаданных (например, devDependencies ), хранение зависимостей в node_modules , пользовательские сценарии, общедоступные и частные реестры пакетов и многое другое, были введены npm.

В 2020 году GitHub приобрел npm, поэтому в принципе npm теперь находится под управлением Microsoft. На момент написания этой статьи самой последней основной версией была v8, выпущенная в октябре 2021 года.

Yarn (v1/Classic), отвечающий за множество нововведений

В сообщении в блоге в октябре 2016 года Facebook объявил о совместных усилиях с Google о разработке нового пакетного менеджера, который решит проблемы с согласованностью, безопасностью и производительностью, которые были у npm в то время. Они назвали альтернативу Yarn, что означает «Yet Another Resource Negotiator».

Хотя архитектра Yarn во многом построена на концепциях и процессах, установленных в npm, Yarn оказал большое влияние на пакетные менеджеры в своем первом релизе. В отличие от npm, Yarn распараллелил операции, чтобы ускорить процесс установки, что было основной проблемой ранних версий npm.

Yarn установила более высокую планку для DX, безопасности и производительности, а также изобрел множество концепций, в том числе:

• Нативная поддержка монорепозиториев
• Установка с поддержкой кеша
• Автономное кэширование
• Файлы блокировки

Yarn v1 перешла в режим обслуживания в 2020 году. С тех пор линейка v1.x считается устаревшей и переименована в Yarn Classic. Его преемник, Yarn v2 или Berry, сейчас является активной веткой разработки.

pnpm, быстрый и эффективно использующий память

Версия 1 pnpm была выпущена в 2017 году Золтаном Кочаном. Это простая замена npm, поэтому, если у вас есть проект использующий npm, вы можете сразу использовать pnpm!

Создатели pnpm решили основную проблему npm и Yarn, которая заключалась в избыточном хранении зависимостей, которые использовались в разных проектах. Хотя Yarn Classic имел преимущество в скорости по сравнению с npm, он использовал тот же подход к разрешению зависимостей, который не подходил создателям pnpm: npm и Yarn Classic использовали подъем для приведения каталога node_modules к плоской структуре.

Вместо подъема pnpm представил альтернативную стратегию разрешения зависимостей: хранилище с адресацией по содержимому. Результатом этого метода является node_modules с вложенной структурой, в которой хранятся пакеты в глобальном хранилище в вашей домашней папке ( ~/.pnpm-store/ ). Каждая версия зависимости физически сохраняется в этой папке только один раз, представляя собой единый источник достоверности и экономя немало места на диске.

Это достигается с помощью макета node_modules с использованием символических ссылок для создания вложенной структуры зависимостей, где каждый файл каждого пакета внутри папки является жесткой ссылкой на хранилище. Следующая диаграмма из официальной документации поясняет это.

Влияние pnpm можно увидеть в их отчете за 2021 год: конкуренты хотят перенять концепции установки pnpm, такие как символическая структура node_modules и эффективное управление пакетами с эффективным использованием дискового пространства, благодаря своим инновациям в области хранения с адресацией содержимого.

Yarn (v2, Berry) заново изобретает велосипед с Plug’n’Play

Yarn 2 был выпущен в январе 2020 года и был заявлен как серьезное обновление оригинального Yarn. Команда Yarn начала называть его Yarn Berry, чтобы было более очевидно, что это, по сути, новый менеджер пакетов с новой кодовой базой и новыми принципами.

Основным нововведением Yarn Berry был подход Plug’n’Play (PnP), который появился как стратегия исправления node_modules . Вместо создания каталога node_modules создается .pnp.cjs файл с таблицами поиска зависимостей, который можно обрабатывать более эффективно, поскольку он представляет собой один файл, а не структуру вложенных папок. Кроме того, каждый пакет хранится в виде zip-файла внутри каталога .yarn/cache/ , который занимает меньше места на диске, чем каталог node_modules .

Все эти внезапные изменения, вызвали много споров после выпуска. Критические изменения PnP требовали от разработчиков обновлять свои существующие пакеты, чтобы быть совместимыми с ним. Совершенно новый подход PnP использовался по умолчанию, и возврат к режиму node_modules был непростым, что привело к тому, что многие известные разработчики открыто критиковали Yarn 2 за это.

С тех пор команда Yarn Berry решила многие проблемы в своих последующих выпусках. Чтобы устранить несовместимость PnP, команда предложила несколько способов легко изменить режим работы по умолчанию. С помощью плагина node_modules для использования традиционного подхода node_modules требуется всего одна строка конфигурации.

Кроме того, экосистема JavaScript со временем все больше и больше поддерживает PnP, как вы можете видеть в этой таблице совместимости, и некоторые крупные проекты перешли на внедрение Yarn Berry. В моем сопутствующем проекте я также реализовал PnP с моим демонстрационным React проектом.

Хотя Yarn Berry довольно молод, он уже оказал влияние на другие пакетные менеджеры — pnpm принял подход PnP в конце 2020 года.

Процесс установки

Пакетный менеджер должен быть сначала установлен в локальной системе каждого разработчика и в системах CI/CD.

npm

npm поставляется с Node.js, поэтому никаких дополнительных действий не требуется. Помимо загрузки установщика Node.js для вашей ОС, стало обычной практикой использовать инструменты командной строки для управления версиями программного обеспечения. В контексте Node очень удобными утилитами стали Node Version Manager (nvm) или Volta.

Yarn Classic and Yarn Berry

Вы можете установить Yarn 1 разными способами, например, как пакет npm с помощью $ npm i -g yarn .

• Установите или обновите Yarn Classic до последней версии 1.x.
• Используйте команду $ yarn set version для обновления до последней современной версии: $ yarn set version berry

Corepack был создан ребятами из Yarn Berry. Первоначально эта инициатива называлась менеджером пакетных менеджеров(pmm) �� и была объединена с Node в LTS v16.

С помощью Corepack вам не нужно устанавливать альтернативные пакетные менеджеры npm «отдельно», потому что Node включает в себя двоичные файлы Yarn Classic, Yarn Berry и pnpm в качестве прокладок. Эти прокладки позволяют пользователям запускать команды Yarn и pnpm без предварительной их явной установки и без загромождения дистрибутива Node.

Corepack поставляется предустановленным с версии Node.js ≥ v16.9.0. Однако для более старых версий Node вы можете установить его с помощью $ npm install -g corepack .

Сначала включите Corepack, прежде чем использовать его. В примере показано, как активировать его в Yarn Berry v3.1.1.

$ corepack enable
# прокладка установлена, но конкретная версия должна быть активирована
$ corepack prepare yarn@3.1.1 --activate

pnpm

Вы можете установить pnpm как пакет npm с помощью $ npm i -g pnpm . Вы также можете установить pnpm с помощью Corepack: $ corepack prepare pnpm@6.24.2 —activate .

Структура проекта

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

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

На этапе установки зависимости сохраняются в файловой структуре (например, внутри node_modules ) и создается файл блокировки. В этом разделе не учитывается настройка рабочих пространств, поэтому во всех примерах показано только одно место, где хранятся зависимости.

npm

При установке $ npm install или более короткой версии $ npm i создаются файл package-lock.json и папка node_modules . Необязательный файл конфигурации .npmrc можно разместить на корневом уровне. См. следующий раздел для получения дополнительной информации о файлах блокировки.

.
├── node_modules/
├── .npmrc
├── package-lock.json
└── package.json

Yarn Classic

Запуск $ yarn cоздает файл yarn.lock и папку node_modules . Файл .yarnrc необязателен; Yarn Classic также поддерживает файлы. При желании можно использовать папку кэша ( .yarn/cache/ ) и место хранения текущей версии Yarn Classic ( .yarn/releases/ ). Различные способы настройки можно увидеть в разделе сравнения конфигураций.

.
├── .yarn/
│ ├── cache/
│ └── releases/
│ └── yarn-1.22.17.cjs
├── node_modules/
├── .yarnrc
├── package.json
└── yarn.lock

Yarn Berry with node_modules

Независимо от режима установки вам придется обрабатывать больше файлов и папок в проектах Yarn Berry, чем в проектах, использующих другие пакетные менеджеры. Некоторые из них являются необязательными, а некоторые обязательными.

Yarn Berry больше не поддерживает файлы .npmrc или .yarnrc ; вместо этого требуется файл конфигурации .yarnrc.yml . Для традиционного рабочего процесса с созданной папкой node_modules вы должны предоставить конфигурацию nodeLinker, которая использует вариант установки node_modules или pnpm.

# .yarnrc.yml
nodeLinker: node-modules # or pnpm

Запуск $ yarn устанавливает все зависимости в папку node_modules . Создается файл yarn.lock , который является более новым, но несовместимым с Yarn Classic. Кроме того, создается папка .yarn/cache/ , используемая для автономной установки. Папка releases является необязательной и хранит версию Yarn Berry, используемую проектом, как мы увидим в разделе, посвященном сравнению конфигураций.

.
├── .yarn/
│ ├── cache/
│ └── releases/
│ └── yarn-3.1.1.cjs
├── node_modules/
├── .yarnrc.yml
├── package.json
└── yarn.lock

Yarn Berry with PnP

Как в строгом, так и в свободном режимах PnP выполнение $ yarn создает файлы .yarn/cache/ и .yarn/unplugged/ , а также файлы .pnp.cjs и yarn.lock . PnP strict — это режим по умолчанию, но для свободного требуется конфигурация.

# .yarnrc.yml
nodeLinker: pnp
pnpMode: loose

В проекте PnP директория .yarn/ , скорее всего, будет содержать директорию sdk/ , обеспечивающую поддержку IDE, помимо директори releases/ . Есть еще больше директорий, которые могут быть частью .yarn/ , в зависимости от вашего варианта использования.

├── .yarn/
│ ├── cache/
│ ├── releases/
│ │ └── yarn-3.1.1.cjs
│ ├── sdk/
│ └── unplugged/
├── .pnp.cjs
├── .pnp.loader.mjs
├── .yarnrc.yml
├── package.json
└── yarn.lock

pnpm

Исходное состояние проекта pnpm выглядит так же, как проект npm или Yarn Classic — вам нужен файл package.json . После установки зависимостей с помощью $ pnpm i создается папка node_modules , но ее структура полностью отличается из-за подхода к хранению с адресацией по содержимому.

pnpm также создает собственную версию файла блокировки, pnp-lock.yml . Вы можете предоставить дополнительную конфигурацию с помощью дополнительного файла .npmrc .

.
├── node_modules/
│ └── .pnpm/
├── .npmrc
├── package.json
└── pnpm-lock.yml

Файлы блокировки и хранилище зависимостей

Как описано в предыдущем разделе, каждый пакетный менеджер создает файлы блокировки.

В файлах блокировки хранятся версии каждой зависимости, установленной для вашего проекта, что обеспечивает более предсказуемую и детерминированную установку. Это необходимо, потому что версии зависимостей, скорее всего, объявлены с диапазонами версий (например, ≥ v1.2.5), и, следовательно, фактически установленные версии могут отличаться, если вы не «заблокируете» свои версии.

Файлы блокировки также иногда хранят контрольные суммы, которые мы рассмотрим более подробно в нашем разделе о безопасности.

Файлы блокировки были функцией npm начиная с v5 ( package-lock.json ), в pnpm с первого дня ( pnpm-lock.yaml ) и в новом формате YAML в Yarn Berry ( yarn.lock ).

В предыдущем разделе мы видели традиционный подход, при котором зависимости устанавливаются в структуру папок node_modules . Это схема, которую используют npm, Yarn Classic и pnpm, причем pnpm делает это более эффективно, чем другие.

Yarn Berry в режиме PnP делает это по-другому. Вместо папки node_modules зависимости хранятся в виде zip-файлов в сочетании с файлами .yarn/cache/ и .pnp.cjs .

Лучше всего иметь эти файлы блокировки в системе управления версиями, потому что это решает проблему «работает на моей машине» — каждый член команды устанавливает одни и те же версии.

CLI commands

В следующих таблицах сравнивается тщательно подобранный набор различных команд CLI, доступных в npm, Yarn Classic, Yarn Berry и pnpm. Это ни в коем случае не полный список, а представляет собой шпаргалку. В этом разделе не рассматриваются команды, относящиеся к рабочей области.

npm и pnpm специально имеют множество псевдонимов команд и параметров, что означает, что команды могут иметь разные имена, например, $ npm install совпадает с $ npm add . Кроме того, многие параметры команды имеют короткие версии, например, -D вместо — —save-dev .

В таблицах я буду называть все короткие версии псевдонимами. Со всеми менеджерами пакетов вы можете добавлять, обновлять или удалять несколько зависимостей, разделяя их пробелами (например, npm update react react-dom ). Для ясности примеры показывают использование только с одиночными зависимостями.

Работа с зависимостями

В этой таблице описаны команды управления зависимостями для установки или обновления всех зависимостей, указанных в package.json , или нескольких зависимостей, указав их в командах.

Запуск пакетов

В следующих примерах показано, как управлять пакетами, выполняющими функции служебных инструментов, во время разработки, иными словами двоичными файлами, такими как ntl, для интерактивного выполнения сценариев. Терминология, используемая в таблице:

• Пакет: зависимость или двоичный файл
• Двоичный файл: исполняемая утилита, которая запускается из node_modules/.bin/ или .yarn/cache/ (PnP)

Важно, что, по соображениям безопасности, Yarn Berry позволяет нам выполнять только те двоичные файлы, которые мы указали в нашем package.json или те, которые указаны в метаданных. pnpm имеет такое же поведение.

Основные команды

В этой таблице описаны полезные встроенные команды. Если нет официальной команды, часто можно использовать стороннюю команду через пакет npm или плагин Yarn Berry.

Файлы конфигурации

Настройка пакетных менеджеров происходит как в файле package.json , так и в специальных конфигурационных файлах. Примеры параметров конфигурации:

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

Большая часть конфигурации содержится в специальном конфигурационном файле ( .npmrc ).

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

 // . 
"workspaces": [ 
"hooks", 
"utils" 
]
>

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

# .npmrc
@doppelmutzi:registry=https://gitlab.doppelmutzi.com/api/v4/projects/41/packages/npm/

Существует множество вариантов конфигурации для npm, их можно найти в документации.

Yarn Classic

Вы можете настроить рабочие пространства Yarn в файле package.json . Аналогично npm, но рабочее пространство должно быть приватным пакетом.

 // . 
"private": true, 
"workspaces": ["workspace-a", "workspace-b"]
>

Любые дополнительные конфигурации сохраняются в файле .yarnrc . Поле метаданных yarn-path принуждает к использованию определенной двоичной версии Yarn каждым членом команды. yarn-path указывает на директорию (например, .yarn/releases ), содержащую определенную версию Yarn. Вы можете установить версию Yarn Classic с помощью команды $ yarn policies .

Yarn Berry

Настройка рабочих пространств в Yarn Berry аналогична тому, как это делается в Yarn Classic, с помощью package.json . Большая часть конфигурации Yarn Berry выполняется в файле .yarnrc.yml . Пример Yarn Classic также возможен, но поле метаданных переименовано в yarnPath .

# .yarnrc.yml
yarnPath: .yarn/releases/yarn-3.1.1.cjs

Yarn Berry можно расширить с помощью плагинов с помощью $ yarn plugin import . Эта команда обновляет файл .yarnrc.yml .

# .yarnrc.yml
plugins: 
- path: .yarn/plugins/@yarnpkg/plugin-semver-up.cjs 
spec: "https://raw.githubusercontent.com/tophat/yarn-plugin-semver-up/master/bundles/%40yarnpkg/plugin-semver-up.js"

Как описано в разделе истории, из-за несовместимости, могут возникнуть проблемы с зависимостями в строгом режиме PnP. Для решения такой проблемы, есть типичное решение: поле метаданных packageExtensions. Пример из сопутствующего проекта:

# .yarnrc.yml
packageExtensions: 
"styled-components@*": 
dependencies: 
react-is: "*"

pnpm

pnpm использует такой же механизм настройки конфигурации, что и npm, поэтому вы можете использовать файл .npmrc . Настройка приватного реестра работает так же, как и с npm.

Благодаря функционалу рабочих пространств в pnpm доступна поддержка многопакетных проектов. Чтобы инициализировать монорепозиторий, вы должны указать расположение пакетов в файле pnpm-workspace.yaml.

# pnpm-workspace.yaml
packages: 
- 'packages/**'

Поддержка монорепозитриев

Что такое монорепозиторий?

Монорепозиторий — это репозиторий, в котором размещается несколько проектов, называемых рабочими пространствами или пакетами. Стратегия организации проекта заключается в том, чтобы хранить все в одном месте вместо использования нескольких репозиториев.

Конечно, это сопряжено с дополнительными сложностями. Yarn Classic был первым, кто привнес эту возможность, но теперь каждый крупный менеджер пакетов предлагает функцию рабочих пространств. В этом разделе показано, как настроить рабочие пространства с помощью каждого из менеджеров пакетов.

npm

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

# Установка зависимостей для всех рабочих пространств
$ npm i --workspaces.
# Запуск команды для одного пакета
$ npm run test --workspace=hooks
# Запуск команды для нескольких пакетов
$ npm run test --workspace=hooks --workspace=utils
# Запуск команды для всех пакетов
$ npm run test --workspaces
# Запуск команды для пакетов, для которых это возможно
$ npm run test --workspaces --if-present

В отличие от других менеджеров пакетов, npm v8 в настоящее время не поддерживает расширенную фильтрацию или параллельное выполнение команд.

Yarn Classic

В августе 2017 года команда Yarn объявила о поддержке монорепозиториев с помощью функции рабочих пространств. До этого момента менеджер пакетов можно было использовать только в многопакетном проекте со сторонним программным обеспечением, таким как Lerna. Это дополнение к Yarn проложило путь к такой реализации монорепозиториев и другими менеджерами пакетов.

Ранее я также писал о том, как использовать функцию рабочих пространств Yarn Classic с Lerna и без нее, если вам интересно. Но в этом посте будут рассмотрены только некоторые необходимые команды, которые помогут вам управлять зависимостями в настройке рабочих пространств.

# Установка зависимостей для всех рабочих пространств
$ yarn
# Отобразить древо зависимостей
$ yarn workspaces info
# Запуск команды для одного пакета
$ yarn workspace awesome-package start
# Установка пакета webpack
$ yarn workspace awesome-package add -D webpack
# Установка react для всех пакетов
$ yarn add react -W

Yarn Berry

В Yarn Berry с самого начала использовались рабочие пространства, потому что его реализация была построена на концепциях Yarn Classic. В комментарии на Reddit главный разработчик Yarn Berry дал краткий обзор функций, ориентированных на рабочие пространства:

• $ yarn add —interactive : позволяет повторно использовать версии из других рабочих пространств при установке пакета
• $ yarn up : обновляет пакет для всех рабочих пространств
• $ yarn workspaces focus : устанавливает зависимости только для одной рабочей области
• $ yarn workspaces foreach : запускает команду для всех рабочих пространств

Yarn Berry широко использует протоколы, которые можно использовать либо в полях dependencies , либо в полях devDependencies файлов package.json . Одним из них является протокол workspace:

В отличие от рабочих пространств Yarn Classic, Yarn Berry явно определяет, что зависимость должна быть одним из пакетов в этом монорепозитории. В противном случае Yarn Berry может попытаться получить версию из удаленного реестра, если версии не совпадают.

 // . 
"dependencies": "@doppelmutzi/hooks": "workspace:*", 
"http-server": "14.0.0", 
// . 
> 
>

pnpm

Благодаря протоколу workspace: , pnpm облегчает проекты монорепозиториев, как и Yarn Berry. Многие команды pnpm принимают такие параметры, как —recursive ( -r ) или —filter , которые особенно полезны в контексте монорепозитория. Его собственные команды фильтрации также является хорошим дополнением или заменой Lerna.

# Удалить для всех рабочих областей
pnpm -r exec -- rm -rf node_modules && rm pnpm-lock.yaml 
# Запустить тесты для всех рабочих областей в контексте @doppelmutzi
pnpm recursive run test --filter @doppelmutzi/

Производительность и эффективное использование пространства на диске

Производительность важна для принятия решений. В этом разделе показаны мои тесты, основанные на одном небольшом и одном среднем проекте. Вот несколько заметок о примерах проектов:

• Ни один тест не использует функции рабочих пространств
• Небольшой проект — 33 зависимости
• Средний проект — 44 зависимости

Я выполнил измерения для трех вариантов использования (UC), по одному разу для каждого из вариантов нашего менеджера пакетов. Чтобы узнать о подробной оценке с пояснениями, взгляните на результаты для проекта 1 (P1) и проекта 2 (P2).

• UC 1: No cache/store, no lock files, no node_modules or .pnp.cjs
• UC 2: cache/store exists, no lock files, no node_modules or .pnp.cjs
• UC 3: cache/store exists, lock files exist, no node_modules or .pnp.cjs

Я использовал инструмент gnomon для измерения времени, затрачиваемого на установку (например, $ yarn | gnomon ). Кроме того, я измерил размеры сгенерированных файлов, например, $ du -sh node_modules .

На моем проекте, с моими измерениями Yarn Berry PnP strict стал победителем с точки зрения скорости установки для всех вариантов использования и обоих проектов.

Вот официальные тесты команды Yarn Berry и pnpm.

Безопасность

npm

npm был слишком снисходителен, когда дело доходило до работы с плохими пакетами, и столкнулся с некоторыми уязвимостями безопасности, которые напрямую повлияли на многие проекты. Например, в версии 5.7.0 при выполнении команды sudo npm в ОС Linux стало возможным изменить владельца системных файлов, что сделало ОС непригодной для использования.

Другой инцидент произошел в 2018 году и был связан с кражей биткойнов. По сути, популярный пакет Node.js EventStream добавил вредоносную зависимость в своей версии 3.3.6. Этот вредоносный пакет содержал зашифрованную полезную нагрузку, которая пыталась украсть биткойн с компьютера разработчика.

Чтобы помочь решить эти проблемы, более поздние версии npm используют алгоритм шифрования SHA-512 в package-lock.json для проверки целостности устанавливаемых вами пакетов.

В целом, npm делает все больше и больше, чтобы закрыть свои бреши в безопасности, особенно те, которые стали более очевидными по сравнению с Yarn.

Yarn

И Yarn Classic, и Yarn Berry с самого начала проверяли целостность каждого пакета с помощью контрольных сумм, хранящихся в yarn.lock . Yarn также пытается предотвратить получение вредоносных пакетов, которые не объявлены в вашем package.json во время установки: если обнаруживается несоответствие, установка прерывается.

Yarn Berry в режиме PnP не страдает от проблем с безопасностью традиционного подхода node_modules . В отличие от Yarn Classic, Yarn Berry повышает безопасность выполнения команд. Вы можете выполнять только двоичные файлы зависимостей, которые вы явно объявили в своем package.json . Эта функция безопасности похожа на pnpm, о которой я расскажу далее.

pnpm

pnpm также использует контрольные суммы для проверки целостности каждого установленного пакета перед выполнением его кода.

Как мы упоминали выше, у npm и Yarn Classic есть проблемы с безопасностью. pnpm избегает этого, потому что его модель не использует алгоритм подъема; вместо этого он создает вложенные папки node_modules , которые устраняют риск нелегального доступа к зависимостям. Это означает, что зависимости могут получить доступ к другим зависимостям только в том случае, если они явно объявлены в package.json .

Это особенно важно в настройке монорепозиториев, потому что алгоритм подъема может иногда приводить к фантомным зависимостям и двойникам.

Использование в популярных проектах

Я проанализировал многие популярные проекты с открытым исходным кодом, чтобы понять, какие менеджеры пакетов используются в настоящее время «элитой разработки». Для меня было важно, чтобы эти проекты активно поддерживались и обновлялись недавно. Это может дать вам другую точку зрения при выборе менеджера пакетов.

Интересно, что на момент написания этой статьи ни один из этих проектов с открытым исходным кодом не использует подход PnP.

Заключение

Текущее состояние пакетных менеджеров на высоком уровне. Мы практически достигли паритета функций среди всех основных менеджеров пакетов. Но все же, они немного отличаются под капотом.

pnpm выглядит как npm, потому что их использование CLI похоже, но управление зависимостями сильно отличается; Метод pnpm приводит к лучшей производительности и лучшему использованию дискового пространства. Yarn Classic по-прежнему очень популярен, но считается устаревшим программным обеспечением, и в ближайшем будущем его поддержка может быть прекращена. Yarn Berry PnP — новичок в этом блоке, но он еще не полностью реализовал свой потенциал, чтобы снова произвести революцию в мире менеджеров пакетов.

На протяжении многих лет многие пользователи спрашивали, кто какие менеджеры пакетов использует, и в целом кажется, что люди заинтересованы во внедрении Yarn Berry PnP.

Цель этой статьи — дать вам множество точек зрения для принятия решения о том, какой менеджер пакетов использовать самостоятельно. Я хотел бы отметить, что я не рекомендую конкретный менеджер пакетов. Все зависит от ваших требований— вы можете выбрать то, что вам подходит!

Спасибо за прочтение! Какой пакетный менеджер вы будете использовать для старта нового проекта?