Это редакционная статья моего последнего JavaScript-бюллетеня, вы можете подписаться здесь .
На прошлой неделе Facebook произвел большой всплеск, объявив о своем новом менеджере пакетов JavaScript, Yarn. Ваша первоначальная реакция может быть похожа на мою, когда я впервые услышал это: не является ли другой менеджер пакетов последним, что нам нужно ?! Казалось, что, несмотря на потрясение, казалось бы, бесконечного парада новых фреймворков, сообщество JavaScript, по крайней мере, остановилось на npm в качестве менеджера пакетов defacto.
Но подождите, прежде чем отправиться в Twitter или в свой блог, чтобы осудить усталость менеджера пакетов, Yarn на самом деле не так уж и плох Начнем с того, что Yarn — это не новый репозиторий пакетов: это скорее замена для клиента npm, предназначенная для устранения некоторых недостатков npm. В качестве дополнительного бонуса, он не только работает с пакетами npm, но и поддерживает Bower! Перейдите в папку проекта с файлом package.json или bower.json, запустите yarn, и вы в деле.
«Хорошо, но я не использую Bower, так почему бы мне перейти на пряжу?» Я слышу, вы спрашиваете. Итак, команда Yarn создала его для решения проблем со скоростью, надежностью и безопасностью, которые были у них при использовании npm в проектах внутри Facebook. Чтобы достичь этого, Yarn генерирует файл блокировки, который помогает ему точно отслеживать, как разрешается каждая зависимость.
Одним из преимуществ файла блокировки является ускорение установки. До сих пор я видел несколько разных рассуждений о том, насколько это существенно (и в некоторых случаях, имеет ли это значение вообще), но здесь есть несколько очень интересных сравнений между Yarn и npm . Еще одна вещь, которую Yarn делает по-другому, — это хранить кэш загруженных пакетов, делая переустановки невероятно быстрыми. Это также означает, что они могут быть сделаны в автономном режиме.
Еще одним важным соображением является обеспечение того, чтобы проект можно было предсказуемо установить на разных машинах. Yarn использует детерминистический алгоритм при определении того, какие зависимости необходимы, чтобы гарантировать, что они всегда установлены в одном и том же порядке. Это позволяет избежать потенциальных трудных для отладки ошибок, которые иногда могут возникать с npm.
Пряжа также повышает надежность процесса установки. Вместо прерывания установки неудавшийся запрос на зависимость будет поставлен в очередь для повторной попытки. Очередь запросов интеллектуально обрабатывается для распараллеливания запросов и минимизации времени загрузки.
Если вы действительно пытаетесь оптимизировать свой проект, Yarn предлагает вариант плоской установки. В вашем проекте может быть несколько пакетов, которые зависят от разных версий конкретной библиотеки. Выбрав плоскую установку, Yarn сообщит вам о каждом пакете, который требуется более чем в одной версии, и позволит вам вручную выбрать, какую версию устанавливать, что устраняет необходимость в нескольких копиях в разных версиях.
Стоит покопаться в документации CLI , так как есть еще несколько интересных команд. Запустив yarn why <package-name> , вы узнаете, почему установлен конкретный пакет, сколько места он занимает и сколько общих зависимостей он использует. yarn clean все еще является экспериментальной, но она попытается удалить ненужные файлы из папки node_modules и освободить место на диске. Другая потенциально полезная команда — это yarn licenses , в которой указывается тип лицензии для каждого пакета, который используется вашим проектом.
Для тех, кто обеспокоен фрагментацией экосистемы пряжи, стоит отметить, что это ни в коем случае не первый сторонний npm-клиент. Сопровождающие npm считают это позитивным событием , утверждая, что Facebook «инвестирует и поддерживает постоянное здоровье сообщества npm». Это отличная новость для разработчиков JavaScript везде ».