Что такое yarn lock
# Разбираемся с 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 файл, шанс, что при установке пакетов что-то отлетит все таки меньше.
Если у вас возникли какие-то вопросы или комментарии, пишите их прямо под этим видео.
Должен ли я зафиксировать файл yarn.lock и для чего он нужен?
Должно ли это быть зафиксировано в хранилище или проигнорировано? Для чего это?
Да, вы должны проверить это, см. Миграция с npm
Зависит от того, что ваш проект:
Более подробное описание этого можно найти в этом выпуске GitHub, где, например, один из создателей Yarn. говорит:
В package.json описываются предполагаемые версии, требуемые первоначальным автором, а в yarn.lock описывается последняя известная исправная конфигурация для данного приложения.
Я вижу, что это два отдельных вопроса в одном. Позвольте мне ответить на оба.
Вы должны зафиксировать файл в репо?
Да. Как упомянуто в ответе ckuijjer, в Руководстве по миграции рекомендуется включить этот файл в репозиторий. Читайте дальше, чтобы понять, почему вам нужно это сделать.
Это файл, в котором хранятся точные версии зависимостей для вашего проекта вместе с контрольными суммами для каждого пакета. Это способ обеспечения согласованности для ваших зависимостей.
Авторы зависимостей могут выпускать обновления версий исправлений, хотя на самом деле вносят существенные изменения, которые повлияют на ваш проект.
Два разработчика, работающие npm install в разное время, могут получить различный набор зависимостей. Что может привести к невозможности воспроизведения ошибки в двух абсолютно одинаковых средах. Это может вызвать проблемы стабильности сборки для серверов CI, например.
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.
Стоит ли фиксировать файл yarn.lock и для чего он нужен?
Следует передать это в репозиторий или проигнорировать? Для чего это?
6 ответов
Да, вам следует проверить это, см. Переход с npm
Я вижу, что это два отдельных вопроса в одном. Позвольте мне ответить на оба вопроса.
Следует ли передать файл в репозиторий?
Да. Как упоминалось в ответе ckuijjer, это рекомендуется в Руководство по миграции, чтобы включить этот файл в репо. Прочтите, чтобы понять, зачем вам это нужно.
Это файл, в котором хранятся точные версии зависимостей для вашего проекта вместе с контрольными суммами для каждого пакета. Это способ yarn обеспечить согласованность ваших зависимостей.
Авторы зависимостей могут выпускать обновления версий патчей, фактически внося критические изменения, которые повлияют на ваш проект.
Два разработчика, запускающие npm install в разное время, могут получить разный набор зависимостей. Это может привести к тому, что ошибка не будет воспроизводиться в двух абсолютно одинаковых средах. Это может вызвать проблемы со стабильностью сборки, например, для серверов CI.
(Я открыл тикет в системе отслеживания проблем yarn, чтобы убедить вас в необходимости использовать поведение по умолчанию для замороженного файла блокировки, см. # 4147).
yarn install может неожиданно изменить ваш yarn.lock, сделав пряжу претензий на повторяющиеся сборки недействителен. Вы должны использовать yarn install только для инициализации yarn.lock и его обновления.
Кроме того, особенно. в больших командах у вас может быть много шума из-за изменений в замке пряжи только потому, что разработчик настраивал свой локальный проект.
Для получения дополнительной информации прочтите мой ответ о пакете package-lock.json от npm, поскольку это также применимо и здесь.
Это также недавно было ясно указано в документации по установке пряжи:
Установите все зависимости, перечисленные в package.json, в локальную папку node_modules.
Файл yarn.lock используется следующим образом:
Да, вы должны это сделать. Дополнительную информацию о файле yarn.lock см. В официальной документации здесь
Да! yarn.lock должен быть зарегистрирован, чтобы любой разработчик, устанавливающий зависимости, получил точно такой же результат! Например, с помощью npm [который был доступен в октябре 2016 года] вы можете установить локальную версию patch (скажем, 1.2.0), пока новый разработчик запуск нового install может получить другую версию (1.2.1).
Думаю, да, поскольку Yarn использует собственный файл yarn.lock: https://github.com/yarnpkg/yarn
Он используется для детерминированного разрешения зависимостей пакетов.
Зачем в 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-проектах?