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.
Должен ли я зафиксировать файл yarn.lock и для чего он нужен?
Должно ли это быть зафиксировано в хранилище или проигнорировано? Для чего это?
Да, вы должны проверить это, см. Миграция с npm
Зависит от того, что ваш проект:
Более подробное описание этого можно найти в этом выпуске GitHub, где, например, один из создателей Yarn. говорит:
В package.json описываются предполагаемые версии, требуемые первоначальным автором, а в yarn.lock описывается последняя известная исправная конфигурация для данного приложения.
Я вижу, что это два отдельных вопроса в одном. Позвольте мне ответить на оба.
Вы должны зафиксировать файл в репо?
Да. Как упомянуто в ответе ckuijjer, в Руководстве по миграции рекомендуется включить этот файл в репозиторий. Читайте дальше, чтобы понять, почему вам нужно это сделать.
Это файл, в котором хранятся точные версии зависимостей для вашего проекта вместе с контрольными суммами для каждого пакета. Это способ обеспечения согласованности для ваших зависимостей.
Авторы зависимостей могут выпускать обновления версий исправлений, хотя на самом деле вносят существенные изменения, которые повлияют на ваш проект.
Два разработчика, работающие npm install в разное время, могут получить различный набор зависимостей. Что может привести к невозможности воспроизведения ошибки в двух абсолютно одинаковых средах. Это может вызвать проблемы стабильности сборки для серверов CI, например.
# Разбираемся с 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-проектах?
UA Blog
Blog on instersting topics
Npm и Yarn – два самых популярных менеджеры пакетов для JavaScript. Если вы не знаете что делают менеджеры пакетов, то они являются естественным способом автоматизации процесса установки, обновления и удаления сторонних модулей, которые хранятся в общей базе модулей. В этой статье будет рассказано в чем разница между двумя самыми популярными менеджерами пакетов для JavaScript – npm и Yarn.
Npm – это менеджер пакетов, входящий в состав Node.js. Он использует клиент командной строки и базу данных, состоящую из общедоступных и приватных пакетов, известной как npm registry. Пользователи могут получить доступ к базе через сайт или через консоль.
Yarn был разработан в Facebook чтобы избавится от недостатков npm. Технически Yarn не является заменой npm, так он берет информацию про модули из базы npm. По сути Yarn это новый установщик который по прежнему базируется на структуре заданной npm. В Yarn доступны все те же пакеты что и в npm, поэтому, переезд с npm на Yarn не требует больших усилий.
Как установить npm
npm распространяется вместе с Node.js, то есть если вы установили Node.js, вы автоматически установили npm. Для проверки успешной установки Node.js используйте следующие команды
Как установить Yarn
Есть два способа: через npm, для этого запустите следующую команду
Хотя некоторые программисты не советуют так делать, так как считают что лучше установить Yarn через менеджер пакетов операционной системы. Например если вы используете brew на Mac, запустите следующую команду:
Для установки Yarn на Ubuntu 16.04 запустите такие команды:
Сравнение Yarn vs npm
Yarn имеет несколько особенностей отличающих его от npm (особенно версии меньше 5.0:
Наличие yarn.lock файла
Управления версиями в файле ‘package.json’ иногда становится беспорядочным. Файл yarn.lock помогает упорядочить эту путаницу. При добавлении новой зависимости, Yarn обновляет yarn.lock файл, принцип работы похож на Gemfile.lock в Ruby. yarn.lock файл гарантирует что на каждом устройстве будет установлена одинаковая версия пакета. lock файлы так называются, потому что они фиксируют версии зависимостей во время их установки. lockfile состоит из отсортированных ключей чтобы гарантировать минимальный изменения в файловой структуре папки node_modules.
В более ранних версиях npm, такая функциональность была реализована с помощью команды упаковывания(npm shrinkwrap). Тем не менее, shrinkwrap файл не генерировался автоматически, и требовал постоянной поддержки и обновления. Чтобы решить эту проблему npm ввел package-lock.json
Процесс установки пакетов
При установки пакета npm выполняет необходимые действия последовательно, в том смысле что каждый пакет должен полностью установится по очереди. Yarn в свою очередь производит несколько установок за один шаг, что делает процесс установки зависимостей менее длительным.
Скорость
Yarn на порядок быстрее всех версий npm меньше 5.0. Когда команда npm выпустила 5 версию они заявили что она будет в пять раз быстрее своих предшественников. Но все же npm остался медленне чем Yarn []
Главная проблема npm, это то что он автоматически запускает код зависимостей и позволяет добавлять зависимости на лету, хотя такие особенности дают много преимуществ, они также создаю уязвимости в безопасности. Так как Yarn устанавливает зависимости только с файлов yarn.lock или package.json он считается более безопасным. Также Yarn проверяет контрольные суммы перед установкой чтобы гарантировать целостность каждого пакета.
Разница при выполнении команд
Кроме своих функциональных преимуществ, Yarn также имеет несколько новых полезных команд.
Установка зависимостей
npm install устанавливает зависимости с файла package.json. Команда yarn install – с файла yarn.lock.
yarn why
Если вам не понятно почему именно этот пакет установился, команда yarn why пройдется по графу зависимостей и поможет вам выяснить.
Добавления пакетов
позволяет добавлять зависимости также как команда npm install
, но также добавляет зависимость в package.json.
Обновления пакетов
Также как и npm update, команда yarn upgrade [package] обновляет версии пакетов до последних версий.
Если вам нужно вручную сгенерировать файл yarn.lock, базируясь на зависимостях из package.json, используйте команду yarn generate-lock-entry. По сути это команда npm shrinkwrap, но ее нужно использовать очень аккуратно потому что файл yarn.lock, перезаписывается каждый раз при установке новой зависимости.
Улучшения npm в версии 5.0
В релиз пятой версии npm было добавлено три весомых улучшения:
1. Сохранения версий: был добавлен package-lock.json файл, и убрана команда npm-shrinkwrap. Это помогло решить проблемы с версиями зависимостей между установками на разных устройствах.
2. Улучшена производительность: npm 5 быстрее своих предшественников
3. Автоматическое добавление в package.json файл при выполнении команды npm install, в предыдущих версиях приходилась запускать эту команду з флагом –save.
До первого официального релиза Yarn, пользователи жаловались на проблемы с производительностью, но эти проблемы вскоре были решены. Так как Yarn поддерживается такой большой компанией как Facebook, все баги фиксят довольно быстро. По этому Yarn должен быть достаточно стабилен сейчас, но если вы столкнулись с какой то проблемой вы всегда можете вернуться к старому доброму npm.
Недостатки Yarn
Несмотря на то, что Yarn считается улучшенной версией npm, он все же имеет несколько нерешенных проблем. Например, одновременное использование npm и Yarn создает конфликты. Чтобы избежать подобных проблем, рекомендуется разделять проект на модули. Еще одной проблемой является большая необходимость в дисковом пространстве, так как Yarn сохраняет зависимости локально.
Yarn vs npm – вывод
Yarn будет все более популярными благодаря своей хорошей производительности, и многочисленным полезным командам. Тем не менее, npm все еще существует и становится все мощнее с каждой новой версией.