Yarn lock что это такое
Yarn или npm: все, что вам нужно знать о них
Yarn это новый менеджер пакетов, совместно созданный Facebook, Google, Exponent и Tilde. Как можно прочитать в официальной документации, его целью является решение целого ряда проблем, с которыми столкнулись разработчики при использовании npm, а именно:
Но не тревожьтесь. Это не попытка полностью заменить npm. Yarn это новый клиент командной строки, скачивающий модули из реестра npm. В самом реестре ничего не меняется — вы можете скачивать и публиковать модули также, как и прежде.
Должен ли теперь каждый срочно перейти на Yarn? Вполне возможно, что вы никогда не сталкивались с этими проблемами, используя npm. В этой статье мы сравним Yarn и npm, чтобы вы могли определиться, что лучше подходит для вас.
Yarn или npm: функциональные отличия
На первый взгляд Yarn и npm кажутся похожими. Но если заглянуть под капот, мы увидим отличия Yarn.
Файл yarn.lock
В идеальном мире семантического версионирования, релизы с патчами не содержат коренных изменений. Но, к сожалению, в реальности это не всегда верно. Стратегия, выбранная npm может привести к тому, что на двух машинах с идентичными файлами package.json будут установлены различные версии пакетов, что может привести к появлению багов.
Параллельная установка
Независимо от того, устанавливается ли пакет с помощью npm или Yarn, при этом решается серия задач. В npm эти задачи выполняются последовательно и отдельно для каждого пакета, это значит, что пока пакет не установлен полностью, следующий пакет будет ждать. В Yarn эти операции выполняются параллельно, что улучшает производительность.
Для сравнения я установил пакет express с помощью npm и Yarn, не используя кэш, файлы shrinkwrap или lock; всего в установке 42 файла.
Я не поверил своим глазам. Повторение дало такие же результаты. Затем я установил gulp со 195 зависимостями.
Кажется, что разница зависит от количества устанавливаемых пакетов, в любом случае Yarn быстрее.
Консольные логи
По умолчанию npm выводит очень много. Например, он рекурсивно перечисляет все установленные пакеты при выполнении npm install
. Yarn с другой стороны, обходится минимумом информации и использует эмодзи (если у вас mac).
Yarn или npm: различия в интерфейсе командной строки
Кроме функциональных отличий, в Yarn также отличаются команды. Некоторые команды npm удалены, некоторые модифицированы, а пара интересных команд добавлена.
yarn global
yarn install
yarn add [–dev]
Аналогично npm install
yarn licenses [ls|generate-disclaimer]
На момент написания в npm нет эквивалента этой команды. Yarn licenses ls выводит список лицензий всех установленных в проекте пакетов, а yarn licenses generate-disclaimer генерирует дисклеймер, содержащий текст всех лицензий всех пакетов в проекте. Некоторые лицензии требуют включать текст лицензии в ваш проект, поэтому этот инструмент весьма полезен.
yarn why
Эта команда смотрит в граф зависимостей и выясняет, почему указанный пакет установлен в вашем проекте. Возможно, вы сами добавили его, а, может, это зависимость установленного вами пакета. Команда yarn why помогает вам с этим разобраться.
yarn upgrade
Эту команду не надо путать с npm update, обновляющей пакеты до самой свежей версии.
yarn generate-lock-entry
Стабильность и надежность
А что, если шумиха вокруг Yarn преждевременна? В первый же день релиза появилось много сообщений о проблемах, но темпы решения проблем поражают. Это показывает серьезную работу по обнаружению и исправлению багов. Если смотреть на количество и типы проблем, Yarn кажется стабильным для большинства пользователей, но он может не подойти для каких-то отдельных случаев.
Учтите, что несмотря на то, что пакетный менеджер может быть очень важен для вашего проекта, это всего лишь пакетный менеджер. Если возникают проблемы, то переустановка пакетов не должна быть сложной, также как и возврат к npm.
Перспективы
Возможно, вы опасаетесь повторения истории с Node.js и io.js. Напомню, что io.js был форком Node.js, созданным несколькими основными разработчиками после разногласий по поводу управления проектом. Меньше, чем через год, обе команды пришли к соглашению, io.js был слит с Node.js и прекращен. Независимо от того, кто был прав, это обогатило Node.js новыми функциями.
Я вижу схожие паттерны между npm и Yarn. Хотя Yarn это не форк, он исправляет некоторые из недостатков npm. Разве будет плохо, если npm учтет это и попросит Facebook, Google и остальных разработчиков Yarn улучшить npm? Хотя об этом слишком рано пока говорить, но я надеюсь, что так и произойдет.
В любом случае, будущее Yarn выглядит светлым. Сообщество проявляет интерес к появлению нового пакетного менеджера. К сожалению, пока отсутствует дорожная карта проекта, поэтому я не знаю, какие сюрпризы Yarn готовит для нас.
Заключение
Я мог бы однозначно рекомендовать попробовать Yarn в каком-нибудь проекте, раньше или позже. Если вы осторожны в установке и использовании новых программ, подождите пару месяцев. В конце концов, npm проверен в боевых условиях, а в мире разработки программного обеспечения это немаловажно.
Если же вы замечали, что вам приходиться ждать окончания установки пакетов npm, то вам самое время ознакомиться с руководством по переходу на Yarn.
Node.js-проекты, в которых лучше не использовать lock-файлы
Автор материала, перевод которого мы сегодня публикуем, говорит, что одна из проблем, с которыми приходится сталкиваться программистам, заключается в том, что у них их код работает, а у кого-то другого выдаёт ошибки. Эта проблема, возможно, одна из самых распространённых, возникает из-за того, что в системах создателя и пользователя программы установлены разные зависимости, которые использует программа. Для борьбы с этим явлением в менеджерах пакетов yarn и npm существуют так называемые lock-файлы. Они содержат сведения о точных версиях зависимостей. Механизм это полезный, но если некто занимается разработкой пакета, который планируется опубликовать в npm, lock-файлы ему лучше не использовать. Этот материал посвящён рассказу о том, почему это так.
Самое главное в двух словах
Lock-файлы крайне полезны при разработке Node.js-приложений вроде веб-серверов. Однако если речь идёт о создании библиотеки или инструмента командной строки с прицелом на публикацию в npm, то нужно знать о том, что lock-файлы в npm не публикуются. Это означает, что если при разработке применяются эти файлы, то у создателя npm-пакета, и у тех, кто этот пакет использует, будут задействованы разные версии зависимостей.
Что такое lock-файл?
Оба эти файла содержат некоторые крайне важные сведения о зависимостях:
Сравнение package.json и lock-файлов
Цель поля dependencies файла package.json заключается в том, чтобы показать зависимости проекта, которые должны быть установлены для его правильной работы. Но сюда не входят сведения о зависимостях этих зависимостей. В сведения о зависимостях могут входить точные версии пакетов или некий диапазон версий, указанный в соответствии с правилами семантического версионирования. При использовании диапазона npm или yarn выбирают наиболее подходящую версию пакета.
Если посмотреть документацию npm по семантическому версионированию, то можно узнать, что значок ^ указывает на то, что подходящей является любая версия пакета, номер которой больше или равен 3.30.3 и меньше 4.0.0. В результате, если в проекте нет lock-файла и выйдет новая версия пакета, то команда npm install или yarn install автоматически установит эту новую версию пакета. Сведения в package.json при этом обновляться не будут. При использовании lock-файлов всё выглядит иначе.
Это крайне полезно в том случае, если вы занимаетесь разработкой проекта наподобие веб-приложения или сервера, так как в CI-окружении нужно сымитировать поведение пользователя. В результате, если мы будем включать lock-файл в репозиторий проекта (например, созданный средствами git), мы можем быть уверенными в том, что каждый разработчик, каждый сервер, каждая система сборки кода и каждое CI-окружение используют одни и те же версии зависимостей.
Почему бы не сделать то же самое при публикации библиотек или других программных инструментов в реестре npm? Нам, прежде чем ответить на этот вопрос, нужно поговорить о том, как устроен процесс публикации пакетов.
Процесс публикации пакетов
В результате получается, что если кто-нибудь устанавливает чей-нибудь пакет, файл package-lock.json в этом участвовать не будет. То, что имеется в этом файле, который есть у разработчика пакета, не будет учитываться при установке пакета кем-то другим.
Это может, по несчастливой случайности, привести к проблеме, о которой мы говорили в самом начале. В системе разработчика код работает нормально, а в других системах выдаёт ошибки. А дело тут в том, что разработчик проекта и те, кто проектом пользуются, применяют разные версии пакетов. Как это исправить?
Отказ от lock-файлов и использование технологии shrinkwrap
Для того чтобы автоматизировать эту операцию, команду npm shrinkwrap можно добавить в раздел описания скриптов файла package.json в виде prepack-скрипта. Того же эффекта можно добиться, используя хук git commit. В результате вы сможете быть уверены в том, что в вашем окружении разработки, в вашей CI-системе, и у пользователей вашего проекта используются одни и те же зависимости.
Стоит отметить, что этой методикой рекомендуется пользоваться ответственно. Создавая shrinkwrap-файлы, вы фиксируете конкретные версии зависимостей. С одной стороны это полезно для обеспечения стабильной работы проекта, с другой — это может помешать пользователям в установке критически важных патчей, что, в противном случае, делалось бы автоматически. На самом деле, npm настоятельно рекомендует не использовать shrinkwrap-файлы при разработке библиотек, ограничив их применение чем-то вроде CI-систем.
Выяснение сведений о пакетах и зависимостях
Вот несколько подобных команд:
Итоги
Многое из того, о чём мы тут говорили, полагается на особенности выполнения различных операций средствами npm. Речь идёт об упаковке, публикации, установке пакетов, о работе с зависимостями. А если учесть то, что npm постоянно развивается, можно сказать, что всё это в будущем может измениться. Кроме того, возможность практического применения приведённых здесь рекомендаций зависит от того, как разработчик пакета воспринимает проблему использования различных версий зависимостей в разных средах.
# Разбираемся с lock файлами в npm
В этом видео мы с вами разберемся, зачем нужны lock файлы, при работе с npm.
Очень много людей считает, что если в package.json указать точные версии пакетов, но они никогда не обновятся и проект в безопасности. Это абсолютно не так. В чем же проблема?
Да, указав версию пакета, например, в 1.5.0 мы всегда будем устанавливать этот пакет именно версии 1.5.0. Но у каждого пакета есть свои зависимости. И мы никогда не знаете, как он их менеджит. Возможно, он не лочит их на конкретной версии. А даже если и лочит, то зависимости зависимостей могут иметь не точные версии. Поэтому, рано или поздно, с большим количеством пакетов на проекте, при очередной установке пакетов все может поломаться и прийдется долго дебажить, почему.
Эту проблему решают с помощью lock файлов. Что это такое? Это дополнительный файл, который генерируется автоматически и хранит в себе полное дерево всех зависимостей с версиями. И после его генерации все пакеты устанавливаются по новой с версиями и зависимостями, которые там указаны.
По умолчанию в npm 5, которая на данным момент последняя, при установке пакетов у вас автоматически создается и обновляется файл package-lock.json. Вам не нужно ничего дополнительно делать. Вы просто должны закоммитить этот файл также, как и обычный файл проекта в репозиторий.
Если же вы используете yarn, вместо npm, то у вас также автоматически генерируется файл yarn.lock, который лочит все версии.
Если же вы все еще используете более старый npm, то lock файл у вас не будет создаваться руками. Для создания его нужно выполнить команду
В результате у вас создастся файл npm-shrinkwrap.json, в котором будут залочены все зависимости.
Какой бы язык или пакетный менеджер вы не использовали, вы всегда должны использовать lock файлы, во избежание дебага обновившихся пакетов.
Также, я бы рекомендовал все всегда использовать точные версии в package.json. Тогда, если кто-то удалит lock файл, шанс, что при установке пакетов что-то отлетит все таки меньше.
Если у вас возникли какие-то вопросы или комментарии, пишите их прямо под этим видео.
Зачем в npm 7 оставили поддержку package-lock.json?
Краткий ответ на этот вопрос выглядит так: «Потому что yarn.lock не полностью удовлетворяет нуждам npm. Если полагаться исключительно на него, это ухудшит возможности npm по формированию оптимальных схем установки пакетов и возможности по добавлению в проект нового функционала». Ответ более подробный представлен в данном материале.
Базовая структура файла yarn.lock
Файл yarn.lock представляет собой описание соответствия спецификаторов зависимостей пакетов и метаданных, описывающих разрешение этих зависимостей. Например:
Вопрос тут заключается в следующем: «Если yarn.lock достаточно хорош для менеджера пакетов Yarn — почему npm не может просто использовать этот файл?».
Детерминированные результаты установки зависимостей
Результаты установки пакетов с помощью Yarn гарантированно будут одними и теми же при использовании одного и того же файла yarn.lock и одной и той же версии Yarn. Применение различных версий Yarn может привести к тому, что файлы пакетов на диске будут расположены по-разному.
Рассмотрим следующий граф зависимостей:
Вот пара схем деревьев зависимостей, каждое из которых можно признать корректным.
Вложенные зависимости и дедупликация зависимостей
Более того, существует целый класс ситуаций, предусматривающих работу с вложенными зависимостями и дедупликацию зависимостей, когда файл yarn.lock не способен точно отразить результат разрешения зависимостей, который будет, на практике, использоваться npm. Причём, это справедливо даже для тех случаев, когда npm использует yarn.lock в качестве источника метаданных. В то время как npm использует yarn.lock как надёжный источник информации, npm не рассматривает этот файл в роли авторитетного источника сведений об ограничениях, накладываемых на версии зависимостей.
В некоторых случаях Yarn формирует дерево зависимостей с очень высоким уровнем дублирования пакетов, а нам это ни к чему. В результате оказывается, что точное следование алгоритму Yarn в подобных случаях — это далеко не идеальное решение.
Рассмотрим следующий граф зависимостей:
На основе этих сведений npm формирует следующее дерево зависимостей:
Так как файл yarn.lock фиксирует лишь порядок разрешения зависимостей, а не результирующее дерево пакетов, Yarn сформирует такое дерево зависимостей:
Все три получившихся дерева зависимостей можно признать корректными в том смысле, что каждый пакет получит те версии зависимостей, которые соответствуют заявленным требованиям. Но нам не хотелось бы создавать деревья пакетов, в которых слишком много дубликатов. Подумайте о том, что будет, если x — это большой пакет, у которого есть много собственных зависимостей!
Фиксация результатов реализации намерений пользователя
Если используется этот флаг, то итоговое дерево для вышеприведённого примера будет выглядеть так:
Вот ещё несколько примеров того, как дополнительные настройки npm способны приводить к созданию отличающихся друг от друга деревьев зависимостей:
Фиксация же структуры готового дерева зависимостей позволяет нам давать в распоряжение пользователей подобные возможности и при этом не нарушать процесс построения детерминированных и воспроизводимых деревьев зависимостей.
Производительность и полнота данных
В npm 7 файл package-lock.json содержит всё, что нужно npm для полного построения дерева зависимостей проекта. В npm 6 эти данные хранятся не так удобно, поэтому, когда мы сталкиваемся со старым lock-файлом, нам приходится нагружать систему дополнительной работой, но это делается, для одного проекта, лишь один раз.
В результате, даже если в yarn.lock и были записаны сведения о структуре дерева зависимостей, нам приходится использовать другой файл для хранения дополнительных метаданных.
Будущие возможности
То, о чём мы тут говорили, может серьёзно измениться, если учитывать различные новые подходы к размещению зависимостей на дисках. Это — pnpm, yarn 2/berry и PnP Yarn.
Мы, работая над npm 8, собираемся исследовать подход к формированию деревьев зависимостей, основанный на виртуальной файловой системе. Эта идея смоделирована в Tink, работоспособность концепции подтверждена в 2019 году. Мы, кроме того, обсуждаем идею перехода на что-то вроде структуры, используемой pnpm, хотя это, в некотором смысле, даже более масштабное кардинальное изменение, чем использование виртуальной файловой системы.
Это — не статья, которую можно было бы назвать «О вреде yarn.lock»
Мне хотелось бы особо отметить то, что, судя по тому, что я знаю, Yarn надёжно создаёт корректные деревья зависимостей проектов. И, для определённой версии Yarn (на момент написания материала это относится ко всем свежим версиям Yarn), эти деревья являются, как и при использовании npm, полностью детерминированными.
Файла yarn.lock достаточно для создания детерминированных деревьев зависимостей с использованием одной и той же версии Yarn. Но мы не можем полагаться на механизмы, зависящие от реализации менеджера пакетов, учитывая использование подобных механизмов во многих инструментах. Это ещё более справедливо, если учесть то, что реализация формата файла yarn.lock нигде формально не документирована. (Это — не проблема, уникальная для Yarn, в npm сложилась такая же ситуация. Документирование форматов файлов — это довольно серьёзная работа.)
Лучший способ обеспечения надёжности построения строго детерминированных деревьев зависимостей, это, в долгосрочной перспективе, фиксация результатов разрешения зависимостей. При этом не стоит полагаться на веру в то, что будущие реализации менеджера пакетов будут, при разрешении зависимостей, идти тем же путём, что и предыдущие реализации. Подобный подход ограничивает наши возможности по конструированию оптимизированных деревьев зависимостей.
Отклонения от изначально зафиксированной структуры дерева зависимостей должны быть результатом явно выраженного желания пользователя. Такие отклонения должны сами себя документировать, внося изменения в зафиксированные ранее данные о структуре дерева зависимостей.
Каким менеджером пакетов вы пользуетесь в своих JavaScript-проектах?
6 качеств, благодаря которым Yarn является лучшим менеджером пакетов для JavaScript
Russian (Pусский) translation by AlexBioJS (you can also view the original English article)
1. Скорость
Одним из достижений Yarn является его скорость работы по сравнению со стандартным клиентом npm. Но насколько он быстр? Недавно проведенное эталонное тестирование показало, что Yarn был в два-три раза быстрее npm. В этом тесте измерялось время установки React, Angular 2 и Ember. Это весьма надежная проверка менеджера пакетов, поскольку каждый из этих фреймворков нуждается во множестве зависимостей и содержит большую долю зависимостей реальных веб-приложений.
Давайте добавим еще одно значение и самостоятельно протестируем скорость путем установки модуля create-react-app при помощи yarn и npm. Ниже приведен результат установки с использованием yarn:
Вот результат установки с использованием npm:
Да. Этот результат бесспорно согласуется с другими сообщениями о значительном преимуществе yarn в скорости. Yarn установил модули за 2.59 секунд, тогда как npm потребовалось 9.422 секунд. Yarn был быстрее в 3.63 раза.
2. Надежность установок
Также yarn может похвастаться более надежными установками, чем npm. Когда установка считается ненадежной? Если при последующих установках происходит сбой или получается другой результат, то установка является ненадежной. Это может происходить по двум причинам:
Yarn справляется с обоими проблемами.
Офлайн кэш
Yarn использует глобальный офлайн кэш для сохранения пакетов, которые вы однажды установили, поэтому при установках новых версий используется кэшированная версия и достигается устойчивость к периодическим сбоям компьютерной сети. Вы можете узнать о расположении кэша yarn у вас при помощи команды:
Вот первые пять пакетов моего офлайн кэша:
Yarn способен на большее. У него может быть полное офлайн зеркало (* копия), которое будет использоваться обновлёнными версиями yarn.
Файл yarn.lock
Файл yarn.lock (* файл для блокировки ресурсов yarn) обновляется каждый раз, когда вы добавляете или обновляете версию пакета. В нем определяется, главным образом, точная версия каждого пакета, которая может быть указана в package.json при помощи частичного определения версии (например, указаны только главный и второстепенный номера версии), и его зависимостей.
Ниже приводится начало типичного файла yarn.lock. Вы можете увидеть версию такую, как она указана в package.json, например, «abbrev@1», и точно определенную версию «1.1.0».
Но почему?
Также yarn предоставляет вам команду yarn why для объяснения причины установки определенного пакета в вашем проекте:
3. Возможность проверки лицензий
4. Совместимость с npm и Bower
Yarn полностью совместим с npm, поскольку является просто другим клиентом, который работает с реестрами npm. В самом начале развития Yarn поддерживал Bower, однако немного спустя было принято решение прекратить поддержку Bower.
Основной причиной была не очень хорошая совместимость с Bower. При этом освобождалась папка bower_components или не доставлялся ни один пакет в новом проекте. Однако другой причиной является то, что команда Yarn не хотела поддерживать разделение в области управления пакетами и, наоборот, предпочитала переключение всех на npm.
Если вы заинтересованы в использовании Bower и не хотели бы переходить на другой менеджер пакетов прямо сейчас, вы по-прежнему можете использовать Yarn, однако, добавьте следующий фрагмент кода в ваш файл package.json.
5. Наличие нескольких реестров
Yarn может работать с несколькими типами реестров. Если вы просто добавляете пакет, то, по умолчанию, Yarn будет использовать свой реестр npm (который не является стандартным реестром npm). Однако, Yarn также может добавлять пакеты из файлов, удаленных tar-архивов с исходным кодом или удаленных репозиториев git (* система контроля версий).
Чтобы посмотреть текущий сконфигурированный реестр npm, выполните:
Для того чтобы установить другой тип реестра, используйте: yarn config set registry
Для добавления пакетов из разных источников используйте следующие команды для добавления:
6. Эмодзи «рулят»!
Одним людям нравятся эмодзи, другим нет. Изначально Yarn отображал эмодзи автоматически, однако только на операционной системе Mac OS X. В результате на Yarn посыпались камни с двух сторон: ненавистники эмодзи были огорчены тем, что их консоль пестрила эмодзи, в то время как любители эмодзи были расстроены отсутствием эмодзи на Windows и Linux.