Yarn: Конкурирующие файлы блокировки создают плохой UX

Добавьте config в package.json, чтобы указать

Это может быть хорошим вариантом использования поля engine 🤔

Цикл обхода package-lock.json → yarn.lock → package-lock.json выполняется с потерями, но это, вероятно, неважно. yarn.lock → package-lock.json → yarn.lock не должно быть с потерями, AFAIK.

С точки зрения npm я предпочитаю вариант, при котором, если yarn видит package-lock.json а не yarn.lock , он импортирует его и удаляет package-lock.json . Точно так же, если npm видит yarn.lock и не видит package-lock.json он должен сделать то же самое, импортируя и удаляя `yarn.lock.

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

Меня это немного беспокоит, потому что это означает, что ни package-lock.json ни yarn.lock не смогут добавлять метаданные в файлы (в настоящее время Yarn этого не делает, но почему бы и нет), удаляя некоторые свобода нашим форматам в процессе.

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

@ yarnpkg / core, мысли?

Мне нравится идея @iarna перенести оба инструмента из одного файла блокировки в
другой при автоматической установке.
Имеет смысл удалить импортированный файл блокировки после миграции, чтобы избежать
оба пакетных менеджера соревнуются в одном проекте.

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

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

В среду, 11 апреля 2018 г., в 21:49 Маэль Нисон [email protected] написал:

Меня это немного беспокоит, потому что это означает, что ни
package-lock.json и yarn.lock не смогут добавлять метаданные в файлы
(Пряжа в настоящее время не работает, но почему бы и нет), что лишает наши форматы свободы
в процессе.

Этот вопрос также поднимает вопрос о совместимости между Yarn и
npm в целом, первоначально обсуждалось в другом потоке - я хочу попробовать
быть слишком совместимым, возможно, заслуживает нас обоих, поскольку в этом случае пользователи
ожидаете, что все будет работать одинаково на обоих
проект, который я считаю опасным предположением (один очевидный пример -
что рабочие области будут молча сломаться, если кто-то запустит npm на
проект на базе рабочей области).

@ yarnpkg / core https://github.com/orgs/yarnpkg/teams/core , мысли?

-
Вы получаете это, потому что входите в упомянутую команду.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/yarnpkg/yarn/issues/5654#issuecomment-380677110 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/ACBdWI9jnLJeFqH8v2T-AB74sQO1PMIjks5tntzrgaJpZM4TQ5-B
.

Pinging @imsnif, так как он выразил заинтересованность в реализации решения «Преобразовать другой файл блокировки» несколько недель назад. Возможно, к настоящему времени у него даже есть рабочий код.

Спасибо за пинг!

Так что да, я на самом деле работаю именно над этим. Я планировал написать RFC пряжи и проверить связь со всеми заинтересованными сторонами на следующей неделе.

Вкратце: я немного поработал над преобразованием yarn.lock <==> package-lock.json. При этом есть некоторые потери, но очень мало из них логичных. На мой взгляд, это вполне приемлемо, если мы говорим о сценарии «одноразового преобразования», упомянутом выше. Если мы хотим обсудить это дальше, я могу остановиться подробнее.

В настоящее время у меня есть элементарный код, который делает это: https://github.com/imsnif/synp
Это не 100% и зависит от существующей и текущей папки node_modules для проекта, который будет преобразован. Я нахожусь на завершающих этапах перезаписи (в ветке 2.0.0 ), которая получит состояние пакета из реестра (с использованием потрясающей pacote lib).

Когда это будет сделано, я хочу начать говорить о том, как (и если?) Мы хотели бы реализовать это в точности как в yarn и в npm .

Хотелось бы услышать мнение каждого по этому поводу.

На мой взгляд, это вполне приемлемо, если мы говорим о сценарии «одноразового преобразования», упомянутом выше.

Я не думаю, что это будет так часто. Возможно, я ошибаюсь, но мне кажется, что наиболее распространенным вариантом использования будут проекты с использованием Yarn, и один из разработчиков копирует / вставляет команду из README, чтобы добавить зависимость, используя npm вместо yarn в процессе.

В этом контексте я все еще не убежден, что это хорошо - терять данные и изменять макет пакета молча, пытаясь поступить правильно - они, вероятно, даже не заметят этого, пока что-то не сломается (у нас может быть запрос подтверждения, но Я ожидаю, что люди, которые копируют / вставляют эти команды, также будут слепо подтверждать запросы на установку). Хуже того, он может работать на их собственной машине, но сломаться у их коллег, когда они снова переключатся на Yarn.

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

Я считаю, что эта функция в основном используется в средах CI, где, я думаю, она может сиять (как упоминалось в OP). Хотя, по крайней мере, я думаю, что оба инструмента должны знать файл блокировки другого инструмента? Оставляя детали того, когда они решат произвести конверсию, на их усмотрение. Что вы думаете?

Я считаю, что эта функция в основном используется в средах CI, где, я думаю, она может сиять (как упоминалось в OP).

У вас есть пример? Системы CI должны действовать очень детерминированным образом, случайная фиксация преобразованного файла блокировки - это то, что должно быть отловлено хуже во время PR, imo, CI слишком поздно для этого.

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

Может быть. Использование версии engine для принудительного использования определенного диспетчера пакетов выглядит более понятным для меня, оба проекта просто должны сохранить список эксклюзивных движков (например, «yarn» не может быть удовлетворено на «npm», и наоборот).

На мой взгляд, преобразование файлов блокировки на лету также не очень масштабируемо. Например, до сих пор мы говорили только о файле package-lock.json , но я думаю, что pnpm имеет свой собственный файл блокировки с именем shrinkwrap.yaml . Было бы неплохо, если бы мы могли найти способ справиться с ними обоими и с любым другим форматом, который мог бы придумать один камень.

Я считаю, что эта функция в основном используется в средах CI, где, я думаю, она может сиять (как упоминалось в OP).

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

Что касается CI:
Моя первоначальная мысль заключалась в следующем: предупреждать при добавлении нового пакета с помощью противоположного инструмента, конвертировать при новой установке (или, более консервативно: терпеть неудачу по умолчанию при новой установке и подробно разрешать преобразование с помощью команды import или флага конфигурации для установки).

Когда я раньше работал в смешанной среде npm / yarn, мы, по сути, делали это вручную с помощью git history. Это был кропотливый процесс, и я уверен, что мы были / не одиноки в этом.

Что касается масштабируемости:
Я хотел бы это объяснить.
Когда выполняется преобразование, создается промежуточное логическое и физическое дерево пакетов (если оно есть в файле блокировки). При преобразовании в желаемый файл блокировки эти деревья используются (или создаются с разумными значениями по умолчанию, если мы выполняем преобразование из yarn и не имеем физического дерева).
Таким образом, мы можем легко конвертировать между другими типами файлов блокировки как (все, что нам нужно сделать, это обеспечить преобразования в / из логического / физического дерева для каждого типа).

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

(Что касается нового инструмента ci от npm - я понимаю, что вы имеете в виду, но я думаю, что это немного опережает текущее обсуждение?)

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

Да, я бы полностью поддержал добавление этой логики преобразования в команду yarn import , это похоже на полезную функцию, которую можно извлечь в отдельный пакет, если / когда мы сможем реализовать плагины Yarn :) Мои комментарии сосредоточившись на поведении по умолчанию, которое мы должны принять.

Начиная с npm@6 , вы должны иметь возможность конвертировать package-lock.json -> yarn.lock без потерь, без предварительной установки. Он должен содержать все необходимые данные, идентификаторы и т. Д. (Pkglock npm @ 6 имеет диапазоны версий в поле requires , что соответствует тому, что использует yarn.lock ?)

О, и вам также понадобится https://github.com/yarnpkg/yarn/pull/5042 для отправки, прежде чем это станет правдой, так как npm не имеет sha1 в pkglock во многих случаи.

@arcanis - фантастика! Как и PR с:

1. Предупреждение при установке и обнаружении файла package-lock.json
2. Предупреждение при добавлении и поиске файла package-lock.json
3. Добавление возможности преобразования из package-lock.json помощью команды import (с последующим удалением файла)
   Быть приемлемым? (просто чтобы у нас было кое-что, что мы можем использовать, чтобы начать разговор о деталях)

@zkat - это здорово про npm@6 ! Если это зависит от меня, я бы предпочел использовать это и вернуться к файлам манифеста, чтобы поддерживать все версии файлов блокировки. Могу я спросить, готовы ли вы реализовать подобное (или, может быть, несколько иное) поведение для npm ?

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

Если под словом «в настоящее время работает» вы имеете в виду «отгрузили», тогда да. знак равно

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

Предупреждение при установке и обнаружении файла package-lock.json

Меня беспокоит, что просто наличие предупреждений о существовании неподдерживаемого файла блокировки не поможет с проблемами, вызванными @jmorrell, которые

Меня беспокоит, что просто наличие предупреждений о существовании неподдерживаемого файла блокировки не поможет с проблемами, вызванными @jmorrell, которые

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

Если это предупреждение, оно должно быть большим и очевидным. Пользователи IME привыкли ожидать, что они будут игнорировать вывод своего диспетчера пакетов, пока он работает.

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

Системы CI должны действовать очень детерминированным образом, случайная фиксация преобразованного файла блокировки - это то, что должно быть отловлено хуже во время PR, imo, CI слишком поздно для этого.

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

Меня беспокоит, что просто наличие предупреждений о существовании неподдерживаемого файла блокировки не поможет с проблемами, вызванными @jmorrell, которые

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

Честный вопрос для тех, кто предлагает предупреждение: есть ли ситуация, когда запуск yarn install или yarn add при наличии package-lock.json не будет ошибкой? То же самое для npm install и yarn.lock

На ум приходит переход с npm на Yarn или с Yarn на npm. Я бы предпочел не добавлять трений, когда кто-то хочет попробовать другие менеджеры пакетов.

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

Еще одно преимущество поля Engine состоит в том, что оно позволит вам точно знать, какую версию диспетчера пакетов следует использовать. Я предполагаю, что это где-то настраивается, но с этой системой это было бы частью обычного рабочего процесса.

Еще одно преимущество поля Engine состоит в том, что оно позволит вам точно знать, какую версию диспетчера пакетов следует использовать. Я предполагаю, что это где-то настраивается, но с этой системой это было бы частью обычного рабочего процесса.

Есть ли поле engine или вы имеете в виду engines ? Я не могу найти никаких документов, относящихся к engine . Извиняюсь, если я что-то упускаю.

Мы поддерживаем указание версий в поле engines : https://devcenter.heroku.com/articles/nodejs-support#specifying -an-npm-version

Пример:

  "engines": {
    "npm": "5.6.x"
  }

У меня есть пара проблем, связанных с использованием этого, чтобы определить, какой менеджер пакетов использовать:

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

• Большинство пользователей никогда не трогают эту конфигурацию. Они разделили старый шаблон, который указывал на Node 0.10 даже если они использовали на своей машине все, что скачали с nodejs.org. Это вызывает нетривиальное количество проблем на Heroku.

• Команды часто не согласовывают, какие версии они установили. Версия Node, npm или yarn, которые они установили, часто совпадает с текущими, когда они запускали проект или когда один из них в последний раз сломался и вынудил их переустановить. Не то чтобы это идеально, но я понимаю, что большинство пользователей npm / yarn - новички, и это добавляет новое препятствие для начала работы.

Пример: «Я клонировал пример проекта hello-world, скачал Node с https://nodejs.org , и это не сработало»

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

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

AFAIK Yarn строго применяет это поле, если вы не передадите флаг для его отключения.

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

Это довольно опасно, особенно при использовании Yarn, поскольку это гарантирует согласованность только в одних и тех же основных версиях Yarn.

Не то чтобы это идеально, но я понимаю, что большинство пользователей npm / yarn - новички, и это добавляет новое препятствие для начала работы.

Как насчет Yarn (а также npm, если идея им нравится) добавления записи "yarn": "^<current_version>" в поле engines чтобы обеспечить некоторую безопасность без слишком большого трения? Мы можем автоматически добавлять это при запуске yarn init , yarn import или когда мы создаем файл блокировки с нуля.

Я мало знаю о Yarn, но я думаю, что лучшим решением было бы добавить парсер package-lock.json в Yarn и не создавать yarn.lock если он существует.

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

@thatlittlegit Тогда вам будет приятно узнать о https://github.com/yarnpkg/yarn/pull/5745 . (npm будет делать то же самое в обратном порядке, поэтому мы окажемся в таком месте, где не имеет значения, с каким файлом блокировки вы работаете или какой инструмент вы выберете.)

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

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

@BYK Здесь, вероятно, будет полезна некоторая история поведения поля двигателя:

В npm @ 1 и npm @ 2 у нас есть package.json именем engineStrict в дополнение к полям engine . Если бы engineStrict было истинным, то поле engine использовалось как _resolution constraint_, и до того, как мы применили диапазон semver к списку версий, версии с несовместимыми механизмами будут отфильтрованы. Это позволит вам делать такие вещи, как npm install foo и получать [email protected] даже если [email protected] было опубликовано, если [email protected] не поддерживалось на вашей платформе. Это _ кажется_ желательным, но на практике было очень запутанным, особенно потому, что документы на веб-сайте были только для самой последней версии.

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

ТАКЖЕ была опция конфигурации engine-strict , которая выполняла то же самое, что и свойство package.json , но применяла ее ко ВСЕМ пакетам.

Начиная с npm @ 3 , мы отказались от поддержки свойства engineStrict package.json и изменили поведение параметра конфигурации engine-strict . Параметр конфигурации теперь превращает предупреждения, которые вы получаете с ним, в ошибки, но не влияет на разрешение.

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

Поскольку в следующем выпуске yarn у нас должна быть возможность импортировать package-lock.json в yarn.lock - я хотел бы вернуться к обсуждению проблемы предупреждения / ошибки.

Как я это вижу: я не думаю, что есть веская причина для того, чтобы в одном пакете были и package-lock.json и yarn.lock файл. Большинство проектов, которые я видел, сознательно рассматривают это как проблему, которую необходимо исправить, а не как желаемую ситуацию (но я, конечно, открыт для исправления).
Как я понимаю из объяснения @iarna выше, поле engine не будет хорошим решением для явного указания, какой менеджер пакетов использует пакет.
Итак, IMO, это ситуация, которая должна вызвать подробную ошибку, которая предложит пользователю либо удалить один файл, либо преобразовать его.

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

Что думают все? @jmorrell , @BYK , @arcanis , @iarna?

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

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

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

(Компонент drop-in replace был особенно актуален, когда npm не создавал файлы блокировки, поскольку не было никакой информации, которую можно было бы там потерять. Это также верно, если # 5745 действительно означает, что Yarn теперь может создавать файл блокировки на основе package-lock.json , но это означает только то, что _project_ может легко заменить npm на Yarn. Однако, поскольку вам все еще нужно проверить новый файл блокировки, все участники должны будут переключиться.)

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

Yarn - это не прямая замена с точки зрения открытого API. yarn add <pkg> vs npm install <pkg> - очевидный пример того, что мы делаем что-то по-другому. У нас, как правило, один и тот же набор функций, но в конечном итоге это два разных инструмента, и иногда у нас есть разные решения одной и той же проблемы.

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

Что касается пряжи, я бы предложил начать с предупреждения (как упоминалось выше)

Я бы с этим справился. Что-то вроде:

WARN Your project seem to contain lock files (package-lock.json, shrinkwrap.json) generated
WARN by other tools than Yarn. It is advised not to mix package managers, in order to avoid
WARN resolution inconsistencies caused by desynchronized lock files.

Кто-то хочет открыть пиар?

С радостью открою пиар, добавляющий предупреждение :)

Является ли желаемое конечное решение здесь полезной ошибкой, когда существует package-lock.json + yarn import ? Насколько я понимаю, удалял / конвертировал противоположный файл блокировки, если он существует автоматически.

Любое решение было бы значительным улучшением для пользователей, но я думаю, что было бы лучше, если бы и yarn, и npm выбрали одну и ту же стратегию (хотя это и не обязательно, если нет согласия, и люди твердо к этому относятся).

@jmorrell - я так понимаю, что автоматическое преобразование здесь - плохая идея.

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

Я надеюсь, что люди npm согласятся с этим?

В идеале я бы хотел, чтобы предупреждение включало что-то об устаревшей ситуации (не уверен в формулировке) и о том, что будущие версии пряжи будут вызывать ошибку. Возможно, ссылка на подробную документацию об этом и о том, как с этим справиться. @arcanis - как вы думаете, это возможно, или вы бы предпочли остаться с поведением warning ?

Если оба инструмента выдают error при наличии нескольких файлов блокировки, я чувствую, что разработчики поймут эту проблему, пока она еще «маленькая», и смогут быстро ее решить (с помощью импорта в качестве ссылки или без) .

@arcanis npm add <pkg> совершенно верно и делает то, что делает Yarn 👼

Что касается pkglock и yarnlock, первоначальное намерение package-lock.json состояло в том, чтобы создать формат, включающий все данные, необходимые любому менеджеру пакетов. Фактически, pkglock с npm@6 можно прозрачно преобразовать в yarn.lock без запуска установщика, поскольку он описывает полное дерево со всеми соответствующими метаданными. Мы сделали это _намеренно_ (например, поле requires ), и мы запросили обратную связь от команд Yarn и pnpm, чтобы убедиться, что все, что мы сделали, было достаточно, чтобы они оба могли использовать либо импортируемый файл блокировки, либо как альтернативный вариант. yarn.lock, к сожалению, является подмножеством с потерями, поэтому обратное неверно, но мы все равно добавим материал для его импорта. npm даже подчинялся бы формам дерева, вычисленным Yarn (в отличие от Yarn, который не подчинялся бы).

Фактически, pkglock начиная с npm @ 6 можно прозрачно преобразовать в yarn.lock без запуска установщика, поскольку он описывает полное дерево со всеми соответствующими метаданными.

Я не думаю, что может (но, возможно, я ошибаюсь, не стесняйтесь указывать на любое заблуждение). Файл блокировки пряжи не поддерживает несколько диапазонов, разрешенных к одной версии. Если у вас есть несколько пакетов, каждый в зависимости от lodash@^1.0.0 , все они будут использовать одну и ту же версию. Это не только оптимизация, но и то, как мы кодируем вещи в нашем файле блокировки.

Файл блокировки npm является деревом, это свойство не гарантируется, и несколько идентичных диапазонов могут в конечном итоге использовать разные версии (что нормально, поскольку это может позволить немного улучшить оптимизацию за счет использования правил разрешения узла). В таких обстоятельствах преобразование package-lock.json -> yarn.lock будет с потерями, поскольку у нас не будет другого выбора, кроме как объединить их в один.

С другой стороны, файл блокировки Yarn может быть относительно без проблем преобразован в package-lock.json, потому что наши правила являются более строгим подмножеством ваших (наши объединенные диапазоны могут быть преобразованы в дерево без потерь, дерево не может быть преобразовано в объединенный диапазон без потерь). Обратите внимание, что я говорю только о самом дереве зависимостей, я не знаком с вашими полями метаданных.

Если честно, я не совсем уверен, говорим мы одно и то же или что-то совсем другое, я просто хотел немного прояснить ситуацию 🙂

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

@imsnif Я не уверен в том, что это ошибка в средах без CI (не вопрос о CI - это то, что обязательно должно вызывать ошибку). Я бы предпочел остановиться на предупреждении, которое просто описывает текущее состояние и объясняет, почему оно не идеально.

Хорошо то, что @jmorrell сможет предоставить нам точные метрики, чтобы увидеть, достаточно ли предупреждения, и на основе этого мы выберем наш следующий шаг.

Является ли желаемое конечное решение здесь полезной ошибкой, когда существует package-lock.json + импорт пряжи?

Да, в сочетании с режимом «обновление до ошибки при CI» * я думаю, что это разумный первый шаг!

(* Этого еще нет, я упомяну об этом в # 5773 Yarn 2.0 WG)

@arcanis - О @zkat (но, пожалуйста, @zkat поправьте меня, если я ошибаюсь или не понимаю), что package-lock.json сохраняет как физическое, так и логическое дерево, а yarn.lock сохраняет только логическое дерево. Итак, как упоминалось ранее, преобразование package-lock.json => yarn.lock => package-lock.json приведет к потере данных физического дерева. ИМО в большинстве случаев это нормально, но есть исключения: например. связанные зависимости.

Мое личное мнение состоит в том, что оба менеджера пакетов могут извлечь выгоду из синхронизации построения физического дерева. Из того, что я видел, мы, вероятно, можем извлечь некоторые четко определенные правила о том, как создается физическое дерево, и оба им следуют (в идеале с помощью модуля, поддерживаемого всеми заинтересованными сторонами). Я думаю, это решит проблему совместимости, некоторые проблемы yarn с связанными зависимостями, при этом позволяя каждому диспетчеру пакетов сохранять свои уникальные особенности. (Хотя, по общему признанию, я новичок в этом обсуждении, поэтому могут быть вещи, о которых я не знаю - мои извинения, если я разбудил несколько спящих собак).

Однако по поводу рассматриваемой проблемы: @arcanis - я попытаюсь предложить здесь еще один аргумент в пользу общих ошибок в этой ситуации, и, если вы не согласны, мы можем остаться с предупреждениями, насколько я понимаю:
Хотя действительно очень важно уловить это на уровне CI, я думаю, что отладить там ошибку будет значительно труднее (в среднем), чем ошибку в локальной среде разработчика.
Если разработчик получает ошибку в своей локальной среде из-за использования неправильного инструмента, он (вероятно) не пойдет ни на шаг дальше. Они просто говорили «ой» и использовали другой инструмент. Это сэкономит огромное количество времени вместо того, чтобы ловить его на CI после разработки функции, а затем возвращаться.
Предупреждение (как уже упоминалось здесь ранее) может быть поглощено многими другими, которые разработчики склонны игнорировать, если статус выхода равен 0.
Что вы думаете?

Также - в ситуации, описанной выше, «чужой» файл блокировки может быть по понятным причинам помещен в .gitignore и поэтому у CI даже не будет возможности узнать об этом. Как рассеянный разработчик, я мог бы подумать: «Ну, это дает мне какое-то неясное предупреждение в моей локальной среде, но оно проходит CI - так что это, вероятно, просто локальная проблема с моей стороны - ну ладно»

Предупреждение (как уже упоминалось здесь ранее) может быть поглощено многими другими, которые разработчики склонны игнорировать, если статус выхода равен 0.

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

Вдобавок, я думаю, вы упускаете из виду пользовательскую историю «Я использую менеджер пакетов и хочу попробовать другой», что, на мой взгляд, очень важно для всех участников, как для сопровождающих, так и для пользователей. Было бы неплохо, если бы люди не могли легко опробовать npm 6 из своего проекта Yarn (или, наоборот, попробовать Yarn из своего проекта npm).

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

Это другая тема, но я не согласен. Я думаю, что существует неправильное представление о том, что Yarn - это npm, что неверно. Если вы хотите импортировать проект в другой с помощью специальной команды, я за это, но незаметное преобразование (или чтение) файлов блокировки из стороннего формата - это рецепт катастрофы:

• он будет игнорировать файлы конфигурации
• он сломает физическое дерево при следующем добавлении / удалении пакета
• любая функция, уникальная для диспетчера пакетов, не будет работать (рабочие области, переопределение разрешения, ссылка :, ...)

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

Верно - не подтверждено никакими данными. Я здесь определенно спекулирую (извините, если я не подчеркнул это). Хотя мы могли бы понять тенденцию исправления предупреждений, мы не сможем понять, насколько это удобно для пользователей и есть ли более удобное решение. Если мы полагаемся на данные, я не думаю, что есть какой-либо результат, кроме «не было абсолютно никаких изменений в частоте ошибок развертывания Heroku», который направит нас к решению общей ошибки.

Я согласен, что очень важно не нарушать рабочий процесс людей. Вот почему я предложил ошибку как критическое изменение в 2.0.0 , с формулировкой в ​​предупреждении, которое предупредит пользователя, что эта ситуация устарела. Я также думаю, что мы можем разрешить использование параметра --force или config, чтобы переопределить это поведение. (Я считаю, что это также касается вашей попытки попробовать другую проблему диспетчера пакетов?)

Это другая тема, но я не согласен. Я думаю, что существует неправильное представление о том, что Yarn - это npm, что неверно. Если вы хотите импортировать проект в другой с помощью специальной команды, я за это, но незаметное преобразование (или чтение) файлов блокировки из стороннего формата - это рецепт катастрофы.

Я думаю, что вы поднимаете здесь важные вопросы, которые я хотел бы затронуть. Но, как вы говорите, это другая тема, и я не хочу сорвать разговор. Может, стоит обсудить это в отдельном выпуске?

Я думаю, что разговор здесь немного сорвался, поэтому я хочу привести его в порядок, добавив некоторые пояснения и резюме:

1. Yarn и npm имеют разное разрешение и стратегии создания физического дерева, и это ключевой фактор для существования обоих проектов.
2. Файлы yarn.lock и package-lock.json были созданы с учетом конкретных целей, и, насколько я могу судить, эти цели не полностью совпадают, но имеют некоторое совпадение.
3. Разница в этих целях не делает формат лучше другого в целом, они просто сводят на нет разные вещи.

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

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

Похоже, автоматическое преобразование потенциально опасно, и неудачная установка без выхода может повредить некоторым людям. Как насчет того, чтобы настроить конфигурацию для yarn, чтобы знать, что файл блокировки пакета предназначен для режима CI? Это сигнал от разработчиков, что они говорят: «Я знаю, что делаю, поэтому, пожалуйста, не пытайтесь защитить меня от любых недоразумений».

Мысли?

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

@BYK - отлично звучит. С одним дополнением: как @arcanis убедил меня здесь и в разногласиях, было бы неплохо также добавить предупреждение в режиме без ci, когда флаг конфигурации не установлен. Чтобы разработчики имели возможность знать, что их CI-сборка может выйти из строя, прежде чем они начнут запускать (а также для защиты от package-lock.json находящегося в .gitignore ).

@arcanis, как упомянул @imsnif : pkglock включает в себя как логическую, так и физическую структуру дерева. Следуя логической версии дерева (которая включает диапазоны, из которых мы вывели данные), вы можете создать yarn.lock в памяти вообще без установки или запуска логики установщика. Просто поиск в дереве :)

Из примечаний к выпуску NPM 5:

Новая стандартизированная функция файла блокировки, предназначенная для совместимости с менеджером пакетов (package-lock.json)

Похоже, что команда NPM рекламирует package-lock.json как универсальное решение; возможно ли (технически) присоединиться к этим силам?

Одно из решений, которое я хотел бы предложить, - это «использовать только package-lock.json если он уже существует». По сути, именно так NPM «мигрировал» из термоусадочной упаковки в файл блокировки json.

Похоже, что команда NPM рекламирует package-lock.json как универсальное решение; возможно ли (технически) присоединиться к этим силам?

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

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

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

Наша статистика показывает, что большинство пользователей Yarn также используют npm. Смешанные _проекты_ встречаются редко, но один человек, работающий над несколькими проектами, некоторые из которых являются npm, а некоторые - Yarn, довольно часто. Проблема еще больше усложняется тем, что скрипты установки, которые запускают npm напрямую, - это вещь.

Я хочу использовать пряжу, но в большинстве проектов, над которыми я работаю, есть только файлы package-lock.json . Я не могу добавить файлы yarn.lock . yarn import работает медленно и / или не работает. В настоящее время мой
_only_ вариант - отказаться от пряжи и перейти на npm.

Я понимаю, что пряжа создается разработчиками только для пряжи для проектов, связанных только с пряжей. Но как насчет остальных из нас?

Привет, @Spongman - yarn import нельзя сломать. Теперь он должен иметь возможность импортировать для вас package-lock.json . Если у вас возникли проблемы, дайте нам знать!

Я сделал # 6103

Привет, @Spongman - я прокомментировал проблему, этот конкретный случай произошел из-за поврежденного package-lock.json . Буду рад узнать о других проблемах.

npm может нормально использовать этот файл package-lock.json . пряжа должна быть более упругой.

Ответил на это в другом выпуске - прошу перенести обсуждение туда, чтобы этот вопрос оставался в теме. Благодаря!

Я внимательно смотрел и участвовал в https://github.com/yarnpkg/yarn/issues/3614 (сейчас 254: +1: s). Сейчас этот вопрос закрыт, и обсуждение перенесено сюда.

Игнорируя практические проблемы, на мой взгляд, лучший UX будет обеспечен опцией, не упомянутой в сводке вверху, но упомянутой @thatlittlegit :

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

Что также подтверждается точкой зрения @BrainBacon :

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

Опять же, игнорируя практические проблемы на минуту, теоретический контраргумент был сделан @iarna в этой ветке (и @jhabidas в другой ветке ):

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

Лично я не думаю, что этот аргумент должен применяться в этом случае, как я сделал в комментарии к другому потоку (с 95: +1: s, 2: -1: s):

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

Однако я думаю, что файлы блокировки находятся за пределами того пространства, где Yarn может разумно сохранять независимость. package-lock.json и composer.lock фиксируются в репозитории вместе с package.json и composer.json . Это не файлы для конкретного инструмента, это файлы для конкретного проекта, указывающие точные версии зависимостей, с которыми проект гарантированно будет работать.

...

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

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

Я считаю, что мы должны признать, что это идеальная ситуация, безупречный пользовательский интерфейс. Однако я понимаю другую точку зрения @iarna :

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

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

Если идеальный сценарий, позволяющий репозиториям быть независимыми от инструментов, определенно недостижим (и я вижу множество комментариев о том, как разные файлы блокировки построены принципиально разными способами и содержат разную информацию), то то, что мы, похоже, идем, кажется примерно вкусный, то есть:

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

Я не думаю, что ни при каких обстоятельствах ни один из них должен преобразовывать и удалять файл блокировки другого пользователя. Это означало бы, что новые разработчики будут постоянно переходить от одного к другому и обратно, в зависимости от того, какой инструмент использует этот разработчик (учитывая, что слишком много людей совершают транзакции с git commit -a ).

Я также не согласен с точкой зрения @imsnif :

Я не думаю, что есть веская причина для того, чтобы в одном пакете были и файл package-lock.json, и файл yarn.lock.

Я считаю самонадеянным диктовать, что разработчик запускает на своем компьютере или в производственной среде. По крайней мере, вежливо не быть более строгим, чем нужно. Если над вашим проектом всегда работает только ваша команда разработчиков, и у них у всех работает одно и то же программное обеспечение, отлично. Но у вас может быть разработчик, которому по какой-то причине намного проще использовать NPM, чем Yarn. И особенно если вы создаете программное обеспечение с открытым исходным кодом, вы хотите, чтобы членам сообщества было как можно проще начать работу. Учитывая, что NPM и Yarn - это просто инструменты для установки одних и тех же зависимостей из package.json , они должны просто работать. Разработчик должен иметь возможность видеть package.json , иметь инструмент для его интерпретации и не беспокоиться больше. Так было до того, как возник конфликт файлов блокировки.

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

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

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

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

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

Я действительно думаю, что в конечном итоге, если два проекта откажутся от своей миссии, чтобы позволить проекту быть независимым от инструментов, тогда им действительно следует прекратить совместное использование файла зависимостей. Пряжа должна переключиться на чтение yarn.json а не package.json . Все остальное просто беспорядочно и сбивает с толку.

Если в файлах блокировки npm уже есть надмножество отношений зависимости, которые поддерживают файлы блокировки Yarn, почему бы не поддержать оба в Yarn? Yarn может переключиться на package.json, и любые дополнительные поля, которые могут понадобиться Yarn, могут быть добавлены в будущем (аналогично тому, как некоторые редакторы SVG, такие как Inkscape, управляют метаданными редактора). Тогда Yarn может иметь тот же формат зависимостей, что и npm, и быть обратно совместимым с yarn.lock, конвертируя файлы блокировки npm в любую структуру, которую Yarn хочет в памяти с потерями.

Я действительно думаю, что в конечном итоге, если два проекта откажутся от своей миссии, чтобы позволить проекту быть независимым от инструментов, тогда им действительно следует прекратить совместное использование файла зависимостей. Пряжа должна переключиться на чтение yarn.json а не package.json . Все остальное просто беспорядочно и сбивает с толку.

Возможно, а может и нет. Безусловно, для этого потребовалась бы массовая ломка инструмента (пряжи). Менее радикальные изменения с более прямыми и измеримыми выгодами остались без внимания.

Я не говорю, что это плохая идея, я просто говорю, что не считаю ее практичной.

Я не говорю, что это плохая идея, я просто говорю, что не считаю ее практичной.

Я согласен, что это большой вопрос. Но я говорю о том, что это кажется ключевой проблемой для проекта.

До сих пор Yarn был инструментом, который разработчики могли использовать вместо NPM для установки зависимостей Node для любого проекта с package.json . Теперь, как вы отметили, требуется, чтобы проекты явно выбирали между Yarn и NPM. Это огромное изменение, и его не следует делать случайно. Это решающий момент, чтобы сделать этот звонок.

На мой взгляд, есть 3 пути вперед:

1. Продолжать заменять NPM, находя способ согласовать Yarn с NPM на всех интерфейсах уровня проекта (стандартизировать файл блокировки)
2. Умышленно отклоняться от NPM, используя явно разные интерфейсы на уровне проекта (например, yarn.json и yarn.lock )
3. Удвойте, предоставив половину интерфейса NPM и другую половину интерфейса. На самом деле это то же самое, что и пункт 2., но большинству людей нравится пункт 1.

Я считаю, что третий вариант здесь сбивает с толку все пространство Node и значительно ослабляет оба инструмента.

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

@nottrobin Я думаю, что вы в основном правы в своем анализе:

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

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

@nottrobin - я согласен с @Vinnl. Как я уже упоминал выше, хотя я не хочу никому рассказывать, как они должны работать, я считаю, что использование yarn и npm для установки зависимостей в одном проекте является антипаттерном.

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

но это практически бесполезно, если другие разработчики добавляют / удаляют зависимости, не соблюдая этот файл блокировки.

Да, я полагаю, что до некоторой степени Yarn был в этой мутной воде с самого начала - существование yarn.lock уже означало, что у него частично был собственный интерфейс. Я думаю, что это всегда было немного беспорядочно, что служило цели Yarn, желая, чтобы люди переходили с NPM на Yarn, но не обратно.

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

Теперь это изменилось, потому что NPM блокирует зависимости. Если я решу привязать проект к Yarn, то теперь я буду обновлять yarn.lock , а не package-lock.json , так что утверждение, что кто-то может эффективно использовать NPM на моем проект.

Похоже, вы говорите, что yarn больше не предназначена для замены npm? Что он должен использоваться только в проектах, связанных только с пряжей?

Я думаю, что если это так, то вы обязаны прояснить этот факт на домашней странице yarn - используйте это или npm, а не оба сразу.

Похоже, вы говорите, что yarn больше не предназначена для замены npm?

Такого никогда не было. Интерфейс несколько имитировал npm, чтобы пользователям было легче понять, как им пользоваться, но с самого начала некоторые вещи работали по-другому. Основная причина, по которой некоторые люди думали, что это простая замена, заключалась в том, что в npm просто не хватало функций для сравнения.

Теперь, когда npm догоняет какой-то аспект и решает реализовать вещи по-другому, он просто начинает показывать, что у нас разные подходы и разные решения (например, недавняя реализованная функция автономного зеркала npm несовместима с существующей). Короче говоря: это никогда не было «безопасным», просто случайно сработало.

Я думаю, что если это так, то вы обязаны прояснить этот факт на домашней странице yarn - используйте это или npm, а не оба сразу.

На самом деле у нас есть инструкции по миграции . Ваше замечание заставило меня заметить, что он, к сожалению, содержит неправильный абзац, который может создать у людей неправильное впечатление 🙁 Мы с радостью примем PR, чтобы изменить этот абзац на что-то более соответствующее нашим рекомендациям (т. Е. Использовать Yarn последовательно в разных командах, чтобы чтобы убедиться, что каждый может извлечь выгоду из различных функций, которые могут использоваться в проекте).

Никогда не было

эээ ... тогда тебе нужно поговорить со своими маркетологами. https://yarnpkg.com/lang/en/docs/

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

У нас нет маркетологов, но мы принимаем хорошие пиары 🙃

В данном конкретном случае это звучит не так уж плохо. Мы взаимодействуем со многими функциями, но не со всеми, и в большинстве случаев миграция безболезненна (в худшем случае это всего за yarn import ).

миграция безболезненна

Меня не очень интересует миграция. Я ищу здесь то, что было обещано (у этих ребят _definito_ есть маркетологи): https://code.fb.com/web/yarn-a-new-package-manager-for-javascript/

Он имеет тот же набор функций, что и существующие рабочие процессы, но работает быстрее, безопаснее и надежнее.

пряжа сегодня не такая.

AFAICT здесь 4 класса пользователей:

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

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

@Spongman, что тебе

@Spongman Я не связан с Yarn, поэтому я думаю, что могу быть более откровенным: в этом выпуске действительно нет смысла заявлять, что, по вашему мнению, формулировка неверна. Если вы считаете, что формулировка неправильная, перейдите на эту страницу в GitHub, нажмите кнопку «Изменить» и отправьте запрос на перенос с лучшей формулировкой. arcanis дал понять, что они открыты для этого.

(Думаю, вы, вероятно, не можете редактировать сообщение в блоге, но веб-сайт, вероятно, здесь самый важный.)

Из ответов @imsnif и @arcanis я вижу, что официальная позиция здесь, похоже,

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

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

Но я думаю, что вы сильно недооцениваете количество людей, которые использовали Yarn именно потому, что они считали, что он поддерживает совместимость с NPM (на уровне проекта), и никогда бы не сделал этого в противном случае. Я считаю, что 254: +1: s и 10: heart: s на https://github.com/yarnpkg/yarn/issues/3614 и 57 голосов за « Стоит ли фиксировать yarn.lock и package-lock.json файлы? ", делают это предельно ясно.

Если Yarn откажется от какой-либо ответственности на этом фронте, я думаю, он потеряет не только @Spongman и мои команды, но и многих других.

Честно говоря, я действительно не понимаю вашей проблемы с использованием только Yarn или только npm. В основном вы говорите: «Эй, я не могу заставить свою команду использовать Yarn, поэтому я заставлю их использовать npm». Для меня это не имеет никакого смысла. Если вы используете функции Yarn, заставьте всех использовать Yarn, а если вы хотите использовать функции npm, заставьте всех использовать npm. Это так просто.

Любое промежуточное звено означает, что, по крайней мере, ваши сборки не совпадают в вашей команде, что противоречит предпосылкам Yarn, как упоминалось ранее. Один из ваших инженеров мог бы начать использовать рабочие области, и это сработало бы, но сломалось бы на npm. То же самое с офлайн-зеркалом. То же самое для разрешений зависимостей. Хуже того, поскольку некоторые поля полностью неизвестны npm, он молча сделает неправильные вещи.

Что касается общения, в сообщении блога на fb не упоминается о замене. Позвольте мне процитировать часть, где представлена ​​Yarn. Это буквально говорит о том, что заменяет рабочий процесс. Думаю, вас смутило выражение «остается совместимым с реестром npm», и это справедливый момент, который вы должны донести до npm, а не для нас (есть npm cli, реестр npm и, конечно же, сама npm Inc).

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

что вам мешает от этого последнего? Вероятно, мы сможем это исправить;)

@zkat Это полезно, спасибо.

@nottrobin - Я не могу говорить о первоначальных намерениях пряжи, потому что меня в то время не было. Однако я работал в смешанной среде yarn / npm с несколькими десятками репозиториев.

Я могу сказать, что тогда всем разработчикам было совершенно ясно, что выбор пряжи / npm был выбором для каждого репо, так же как и выбор экспресс / hapi, mobx / redux и т. Д. Это стало еще более ясным, когда npm @ 5 вышел с собственным форматом файла блокировки, и некоторые разработчики решили начать использовать его с новыми репозиториями.

Когда разработчик установит зависимость с неправильным инструментом, это создаст беспорядок даже до npm @ 5 , потому что эта зависимость не будет постоянно заблокирована. Это вызвало проблемы в различных средах, и всем участникам было ясно, что это ошибка *.

Я понимаю, что это может сбивать с толку - и я понимаю, что это может быть не для всех на 100% ясным не по их вине, но я не считаю правильным радикально менять инструмент, чтобы соответствовать этому недоразумению. На мой взгляд, yarn - это замена npm для каждого репо, а не для каждого блока.

* Конечно, эта конкретная ситуация с несколькими репозиториями, не относящимися к рабочему пространству, со смешанными инструментами yarn / npm, не была идеальной на человеческом уровне, а не на техническом уровне именно для этих потенциальных ошибок, и в конечном итоге она была исправлена. Я использую этот пример, чтобы показать, что два инструмента могут работать бок о бок при правильном подходе.

Честно говоря, я действительно не понимаю вашей проблемы с использованием только Yarn или только npm.

Да, вы @arcanis и @imsnif дали понять, что не понимаете. Единственное, что я хочу сказать, это то, что многие люди (посмотрите на: +1: s) сделали одну и ту же «неправильную» интерпретацию и хотят, чтобы Yarn работал вместе с NPM, независимо от того, понимаете вы это или нет. Если пряжа для нас не инструмент, пусть будет так.

(И последнее замечание - @imsn, если совершенно нелепо сравнивать инструмент для установки зависимостей Node с выбором проекта, например, express vs hapi, mobx vs redux. Это фундаментальные характеристики вашего приложения. Если вы не видите очевидной разницы, неудивительно, что вы не понимаете мою точку зрения.)

В любом случае, я закончил. Думаю, я изложил свою точку зрения так хорошо, как мог.

Для проектов с открытым исходным кодом никогда не стоит принуждать «команду» использовать yarn или npm. Вопрос в том, что всем удобнее. В реальном мире npm - король, поэтому, если yarn не может хорошо играть в мире npm, он мертв.

^ Это

Боюсь, это тоже заблуждение. За последний год Yarn увеличилась с 20% от общего количества запросов в реестр npm до 40% в апреле . В последний раз, когда я слышал статистику (прямо от ребят из npm, поскольку наша статистика недавно сломалась, когда реестр npm перешел в Cloudflare), это было около 48% запросов. В реальном мире Yarn и npm сосуществуют, просто и понятно.

Я был бы признателен, если бы мы могли вернуться к обсуждаемой теме, а именно: кто готов написать PR, чтобы написать предупреждение, когда мы обнаруживаем файл package-lock.json во время установки? Благодарю.

Psst, @arcanis - https://github.com/yarnpkg/yarn/pull/5920

Потрясающе: heart_eyes:

Между этим и вашей работой над yarn import , можем ли мы тогда закрыть эту проблему?

Я думал, мы подождем, пока @jmorrell предоставит нам некоторую статистику того, как это влияет на проблему на Heroku, чтобы мы могли решить, достаточно ли этого или мы хотели бы что-то изменить (предупреждение / ошибка и т. Д.) Wdyt?

EDIT: предупреждение еще не выпущено, поэтому у нас еще есть время подождать.

Боюсь, это тоже заблуждение.

Как же так? Объем трафика в npm ничего не говорит вам о том, является ли проект открытым или нет.

более точной оценкой будет подсчет того, какие проекты github имеют 0,1 или 2 из (yarn.lock, package-lock.json). лично я _ никогда_ не видел проект с открытым исходным кодом (любого заметного размера) на github, в котором есть файл yarn.lock и _no_ package-lock.json (кроме очевидного).

ИМО, если вы собираетесь хранить отдельные файлы блокировки, то ОБА менеджеры пакетов должны обнаруживать другой файл блокировки и ОШИБКУ (возможно, с флагом переопределения).

Все - прошу оставаться в теме и убирать любые комментарии, не имеющие прямого отношения к теме (например, наш канал в Discord). На эту ветку подписалось много людей, и, честно говоря, я считаю, что обсуждение пряжи npm <> здесь неуместно. Благодаря!

Я не прочитал весь протектор, но пользователь IHMO должен быть хотя бы уведомлен о двусмысленности:

если npm видит файл yarn.lock, тогда npm должен напечатать что-то вроде:
«ВНИМАНИЕ: похоже, в этом проекте используется yarn, возможно, вам стоит использовать yarn вместо npm install»

если yarn видит файл package-lock.json, тогда yarn должна напечатать что-то вроде:
«ВНИМАНИЕ: похоже, в этом проекте используется npm, возможно, вам стоит использовать npm install вместо yarn»

И, как предлагалось выше, способ «предпочесть» диспетчер пакетов (в package.json).

Я могу сказать, что тогда всем разработчикам было совершенно ясно, что выбор yarn / npm был выбором для каждого репо, как и выбор express / hapi, mobx / redux и т. Д.

Мне это было совершенно непонятно. До сих пор я думал, что это выбор локального разработчика, и несколько разработчиков могут сосуществовать в одном репо, используя то, что им нравится, в то время как было _ немного удобнее_ использовать только одно последовательно. Однако примеры express / hapi и т. Д. Хороши и дают понять, что это не выбор. Это должно быть более заметным.

Добавьте поле в package.json, чтобы указать, какой менеджер пакетов должен использовать проект.

"package-manager": "yarn"

Думаю, это лучшее решение, если оно реализовано во всех менеджерах пакетов.

Тогда менеджеры пакетов ДОЛЖНЫ на 100% отказаться от продолжения, если они вызываются в неправильном проекте, так же, как вы ожидали бы ошибки, если бы вам потребовалось сокращение, но затем вы попытались вызвать для него функции mobx. Они должны выдавать ошибку, а не предупреждение, и сообщать пользователю, как действовать с правильным диспетчером пакетов.

Добавьте поле в package.json, чтобы указать, какой менеджер пакетов должен использовать проект.
"package-manager": "yarn"

Думаю, это лучшее решение, если оно реализовано во всех менеджерах пакетов.

Если вы хотите, чтобы npm обдумал это, я призываю вас начать обсуждение в соответствующем месте , но я скажу, что мне не нравится это направление. Я хотел бы видеть сближение менеджеров пакетов, а не расхождения.

Я бы не рекомендовал использовать какое-то новое поле «package-manager», вместо этого рекомендуя существующую строфу engines которой уже есть предшествующий уровень техники.

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

https://yarnpkg.com/en/docs/package-json#engines -
https://docs.npmjs.com/files/package.json#engines

Даже если ни npm, ни yarn не проверяют engines наличие «конкурирующего» менеджера (что было бы неплохо), использование этого поля по-прежнему является отличным способом сообщить другим разработчикам, какой менеджер предполагается использовать. (если наличие package-lock.json или yarn.lock недостаточно для понимания)

Я хотел бы видеть сближение менеджеров пакетов, а не расхождения.

Согласовано. Либо схождение, либо отказ.

но нынешняя двусмысленная, ошибочная компромиссная позиция вредна.

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

Если вы хотите, чтобы npm обдумал это, я призываю вас начать обсуждение в соответствующем месте.

Спасибо, я только что зарегистрировался. В этом направлении есть недавняя ветка: https://npm.community/t/npm-install-should-warn-about-the-presence-of-yarn-lock-files/1822

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

Я хотел бы видеть сближение менеджеров пакетов, а не расхождения.

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

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

Добавление ошибок теперь позволяет избежать путаницы и не останавливает усилия в направлении конвергенции.

Я бы порекомендовал не использовать какое-то новое поле "package-manager", вместо этого рекомендуя существующие строфы двигателей, которые уже имеют предшествующий уровень техники.

Звучит разумно. Я не привязан к какому-либо конкретному методу обнаружения несовместимого диспетчера пакетов.

Чтобы добавить иллюстрацию, в частности, мой вариант использования - gatsbyjs. Ситуация точно такая же, как сообщает @gaearon здесь :

Для пользователей Create React App это чрезвычайно сбивает с толку, потому что их проект создается с помощью Yarn (если Yarn существует в системе), но затем они следуют документам какой-то библиотеки, которая сообщает им об установке npm, и это сдувает все дерево.

Чтобы избежать этой проблемы, хотя Гэтсби использует пряжу, он также добавляет package-lock.json к стартерам по

Спасибо всем за ваш вклад.

@jmorrell - https://github.com/yarnpkg/yarn/pull/5920 был выпущен 25 июля в 1.9.2 . Прошло чуть больше месяца, я знаю, что это не так много времени (и уж точно не все обновили) - но, может быть, у вас есть какие-нибудь идеи относительно ошибок двойной блокировки файлов на Heroku с тех пор?

@imsnif Спасибо за напоминание по электронной почте! Приносим извинения за отсутствие обновления здесь.

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

(Я отредактировал шкалу y, но она представляет 100 разработчиков и показывает тенденцию)

1. Падение в июле связано с не связанной проблемой с S3.

2. Глядя на тенденцию после 25 июля, кажется, что предупреждение существенно повлияло на количество людей, столкнувшихся с этой ошибкой. Я несколько удивлен величиной сдвига.

@jmorrell - это действительно здорово!
Признаюсь, я тоже этому очень удивлен.

Думаю (что касается пряжи) этот вопрос можно считать решенным. Ты согласен?

Я все еще думаю, что совет по удалению package-lock.json для исправления ошибки вводит в заблуждение - это, как правило, приводит к использованию другого набора версий пакета и (опять же, в общем) приводит к несовместимости и поломкам. кроме того, этот совет полезен только для тех, кто принимает решение о том, какой менеджер пакетов использует проект. основные участники, следующие этому совету, также столкнутся с проблемами.

ИМО, если существует package-lock.json и yarn не может гарантировать, что устанавливаемые им версии совпадают с теми, которые установит npm , тогда он должен завершиться с ошибкой .

Еще раз спасибо за ваш вклад @Spongman. Я чувствую, что все это хорошо обсуждалось в (очень длинной) ветке выше нас, и я не думаю, что имеет смысл перезапускать его снова. Думаю, мы все понимаем вашу позицию. Спасибо за участие.

Если @jmorrell не скажет мне иное в течение следующей недели, я считаю, что это сделано, и закрываю эту проблему.

@imsnif Если

Я не видел никаких движений от npm по этому поводу, поэтому я создам PR, добавив туда предупреждение и посмотрю, как оно будет принято.

Думаю (что касается пряжи) этот вопрос можно считать решенным. Ты согласен?

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

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

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

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

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