Yarn: Добавить средство для установки зависимостей одноранговых пакетов для разработки / тестирования

Созданный на 27 окт. 2016  ·  72Комментарии  ·  Источник: yarnpkg/yarn

Вы хотите запросить _функцию_ или сообщить _ об ошибке?
Характерная черта

Каково текущее поведение?
Нет данных

Какое поведение ожидается?
Предоставьте команду CLI yarn install --peer которая установит одноранговые зависимости, указанные в package.json . Таким образом, при разработке / тестировании могут использоваться партнеры, такие как react / ng2 / grunt.

cat-feature help wanted triaged

Самый полезный комментарий

+1 это важно для авторов библиотеки

Все 72 Комментарий

@ jpollard-cs Я не имею в виду добавление пакета как одноранговую зависимость, я имею в виду наличие средств для установки всех пакетов, перечисленных в настоящее время как одноранговые зависимости.
В противном случае нет эффективных средств разработки плагинов.

npm install
Установит все пакеты, указанные в разделе зависимостей package.json.

yarn add --peer
Я ожидал, что это установит все пакеты, объявленные в разделе package.json peerDependencies.

Есть ли способ установить заявленные пакеты в peerDependencies?

Мой вариант использования - разработка / тестирование собственного модуля реакции.

Вот проблема с NPM, которую они закрыли: https://github.com/npm/npm/issues/11213

Очевидно, это не важно для разработчиков NPM.

+1 это важно для авторов библиотеки

Я уже писал об этом по вопросу NPM, но для людей из Yarn:

Я написал программу cli для установки одноранговых зависимостей пакета:

# If you're using npm
npm install -g install-peerdeps

# If you're using yarn
yarn global add install-peerdeps

cd my-project-directory

install-peerdeps <package>[@<version>]

# for example
install-peerdeps @angular/core
# will install all of angular's peerdeps

Если у вас возникли проблемы с этим, пожалуйста, откройте вопрос по репо!

@nathanhleung ,

Я исправил это с помощью пакета https://www.npmjs.com/package/@team-griffin/install -self-peers

@nathanhleung, ты

Хм ... Если нужны зависимости для разработки / тестирования, не стоит ли помещать их в devDependencies ? Не пытаюсь сбросить бомбу или что-то в этом роде ...

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

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

Пример использования

Пакет ищет правила, доступные в ESLint, которые не настроены в вашей конфигурации.
Чтобы это имело смысл для пользователя, ему необходимо проверить установленный им пакет ESLint, а не какую-то конкретную версию, с которой поставляется ваш пакет (или latest ).
Итак, это зависимость peer .

Теперь, если вы хотите внести свой вклад в проект, вы хотите, чтобы ESLint был установлен в node_modules, чтобы вы могли протестировать свой код, не выполняя npm-link с фиктивным проектом, который устанавливает ESLint.

Когда пользователь запускает yarn , система не должна устанавливать peer deps и предупреждать об их отсутствии (это работает).

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

Интересный момент

  • yarn add <package> --peer устанавливает его в node_modules и добавляет в package.json
  • yarn add <other_package> после этого удаляет установленный пакет из node_modules

В настоящее время я слежу за моделью yarn install --peer для установки dependencies , devDependencies и peerDependencies но для меня это работает так же хорошо.

Если я правильно понимаю @kyleholzinger / @gaastonsr , вы не собираетесь устанавливать peerDependencies в режиме разработки ( cd -ed в репо / пакет, в котором есть peerDependencies , свежий клон, необходимо разработать на этих одноранговых узлах), но добавить их в целевой проект после установки пакета, который имеет одноранговые зависимости?

Чтобы уточнить: вы устанавливаете eslint-find-rules который жалуется, что вам нужен eslint в качестве зависимости (это peerDependency из eslint-find-rules ), поэтому теперь вам нужен простой способ добавления этих зависимостей в peer вы работаете (текущий проект, который зависит от eslint-find-rules )? Что-то вроде «Разрешить и добавить как новые зависимости (изменить package.json и yarn.lock ), наиболее подходящие зависимости одноранговых узлов, требуемые моими текущими зависимостями»?

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

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

Есть над чем подумать.

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

Это то, что я ищу. Установка peerDependencies при разработке пакета.

Да точно @nikolakanacki! Я чувствую, что у нас есть прекрасная возможность помочь людям с управлением их сверстниками.

@gaastonsr нужно добавить в devDependencies тогда - это так просто. В противном случае ваш пакет будет поврежден для разработки. После клонирования проекта и запуска yarn все должно быть установлено, и вы сможете запускать тесты и т. Д.

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

  1. Мой пакет зависит от этого пакета, но я ожидаю, что целевой проект будет включать его, поскольку мой пакет является просто плагином для этого пакета: поместите его в peerDependencies .
  2. У меня есть тесты, которые зависят от этого пакета, но он не указан в моем dependencies (и не должен там указываться) по какой-либо причине: поместите его в devDependencies .

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

@nikolakanacki Когда мы создаем плагин для пакета, мы должны зависеть от версии пакета, установленной пользователем, если мы добавим его как devDependency , мы неизбежно установим другую версию, и она будет использоваться вместо версия пользователя.

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

Сейчас это не так:

@alexilyaev Я думаю, что @nikolakanacki означает установить его как peerDependency, так и devDependency.

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

@alexilyaev объявляя peerDependency вы также объявляете его версию. Если в целевом проекте не установлена ​​версия этой одноранговой зависимости, которая также соответствует указанной вами версии - yarn / npm сообщит об ошибке (отсутствует одноранговая зависимость, что-то в этом роде).

Тем не менее devDependency имеет к этому никакого отношения, это тот, который устанавливается при запуске yarn или npm install внутри исходного пакета (тот, который объявляет одноранговую зависимость, например : плагин), и к нему даже не обращаются, когда пакет используется сторонним пакетом / проектом (партнером).

Дело в том, что я не понимаю, насколько все это актуально?

Я вижу боль от их синхронизации, но вы легко можете написать сценарий bash / javascript / <whatever> который будет проверять это как шаг после установки на package.json .

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

С другой стороны, yarn ввел еще более строгую политику, когда дело доходит до этого, он очищает пакеты, не определенные иначе как dependencies или devDependencies поэтому вы не запускаете в вопросы позже.

@nikolakanacki Допустим, мой плагин принимает ^7.0.0 а последний из одноранговых узлов - 7.9.0 а пользователь определен в их package.json 7.4.0 .
если у меня будет ^7.0.0 в devDependencies , не будет ли Yarn установить (для пользователя) одновременно 7.9.0 и 7.4.0 ?

Если это так, мой плагин может по ошибке использовать установленный 7.9.0 вместо 7.4.0 .

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

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

~ Он предупредит вас, что у вас есть несовместимость peerDependency , ваш плагин ожидает ^7.0.0 и у вас есть версия 7.4.0 . ~ Обновлено: ^7.0.0 удовлетворяет 7.4.0 .

не будет ли Yarn устанавливать (для пользователя) и 7.9.0, и 7.4.0?

Yarn не устанавливает для вас peerDependencies и не устанавливает devDependencies вашего плагина только зависимости в dependencies .

@gaastonsr, вы абсолютно правы, за исключением того, что ^7.0.0 удовлетворяет 7.4.0 .

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

Диапазоны Semver объяснены npm: https://docs.npmjs.com/misc/semver
В случае сомнений всегда проверяйте: http://jubianchi.github.io/semver-check/

@nikolakanacki, чтобы иметь возможность легко устанавливать взаимозависимости пакетов, было бы здорово!

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

Итак, это решает проблему местного развития.

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

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

В чем здесь актуальная проблема? Не похоже, что установка одного списка deps была бы более сложной, чем установка другого списка deps. Зависимости от сверстников существуют уже несколько лет. Как это никого не беспокоило?

Решение @nikolakanacki имеет смысл. Это то, что мы используем для разработки нашей библиотеки. Вам необходимо правильно настроить devDependencies в библиотеке для изолированного тестирования (вне основного проекта, который предоставляет необходимые peerDependencies ), и вам нужен peerDependencies для интегрированного тестирования и обеспечения хоста проект не заканчивается избыточными / дублированными установками пакетов, потому что библиотеки, которые он использует, используют те же dependencies и _ not _, правильно используя peerDependencies и devDependencies .

Их синхронизация вызывает небольшую головную боль. Но, как указал @nikolakanacki , это можно легко смягчить с помощью сценариев post-install .

Какое решение?

Я достаточно быстро просмотрел комментарии и не заметил простого решения:

Всегда устанавливайте peerDependencies как обычные зависимости, если он находится в пакете верхнего уровня

Он идеально подходит для разработки / тестирования и не влияет на установку пакета как зависимости. Аналогично логике для yarn.lock. Нет необходимости в дополнительной «разработке» или каком-либо другом режиме.

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

Совершенно согласен, если вы запустите «yarn install» в репо, он должен установить все одноранговые зависимости, которые еще не указаны в deps. Я действительно не понимаю, чем это отличается от зависимостей разработчиков в этом отношении - если вы разрабатываете этот модуль, вам _необходимо_ установить эти модули.

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

Не стесняйтесь открывать снова с разъяснением или сообщением о новой ошибке.

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

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

Добавление зависимостей одноранговых узлов также в качестве зависимостей разработчиков, как предлагается далее в этом потоке, нарушит типизированный поток: https://github.com/flowtype/flow-typed/issues/379

@andvgal Я просто пытаюсь привести в порядок проблемы, и все обсуждения здесь, которые

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

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

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

Я думаю, что идея добавления переключателя --peer для установки прекрасна, но на самом деле мне нравится иметь возможность устанавливать их один за другим, поскольку я часто связываю некоторые из этих модулей и переключаюсь между ссылкой и на самом деле установив модуль. С npm я могу просто запустить npm i'. В Yarn я не вижу эквивалента. В частности, я хочу иметь возможность установить один файл, используя спецификации в package.json, без изменения файла package.json.

@jimsugg , я использовал yarn add <package...> -p , чтобы вручную установить зависимости одноранговых узлов , уже перечисленные в package.json, что определенно является анти-шаблоном. Похоже, что одноранговые зависимости должны автоматически устанавливаться в средах разработки (если это фактически одноранговая зависимость, тогда должны быть по крайней мере тесты, требующие пакета).

Я искал то же самое и придумал этот однострочный Bash для установки всех перечисленных одноранговых deps (требуется, чтобы у вас был установлен jq): yarn add $(jq -r '.peerDependencies|keys|join(" ")' package.json) .

Надеюсь, это поможет кому-то другому.

@EdwardDrapkin Спасибо за эту легендарную идею! Я расширил его и в итоге добавил для этого сценарий npm:

"install:peers": "yarn add -P $(jq -r '.peerDependencies | to_entries | map(\"\\(.key)@\\(.value | tostring)\") | join(\" \")' package.json)",

Просто поддерживает спецификацию версии из peerDependencies ;) Только заминка здесь после - это если вы не хотите использовать тег latest , а другой, над которым вы работаете, например next или что-то в этом роде.

@shousper вот способ без зависимости jq :

node -e "const peers = Object.entries(require('./package.json').peerDependencies || {}).map(d => d.join('@')).join(' '); if (peers.length) process.stdout.write('yarn add -P --no-lockfile ' + String(peers));" | sh

Есть ли сценарий, при котором вы не хотели бы устанавливать одноранговую зависимость пакета Foo когда вы работаете непосредственно с Foo ? Я не могу вспомнить ни одного. Если Bar требуется использовать Foo , вам это нужно при работе на Foo , и так как это равноправное зависимость, она не может быть регулярной зависимости. Тогда его нужно будет установить только при работе непосредственно с пакетом, что и делают зависимости dev.

Из-за этого я думаю, что yarn имеет смысл рассматривать peerDependencies так же, как devDependencies, но затем также делать то, что они делают сейчас, а именно генерировать предупреждения. Обычно я просто делаю зависимость каждого однорангового узла зависимостью от разработчика, чтобы избежать дублирования.

Есть ли причина, по которой это может стать проблемой? Вероятно, это будет критическое изменение, поэтому придется подождать до версии 2.0, но в остальном, похоже, все будет в порядке.

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

peerDepdency: react@^16.0.0
devDependency: react@~16.1.0

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

Я согласен с @bdwain , я семантически понимаю, в чем разница между зависимостями peer и dev, но на практике они устанавливаются точно так же; если вы разрабатываете модуль, вам необходимо установить и dev, и peer dependencies, а если вы используете модуль, то вы устанавливаете только его перечисленные фактические зависимости. Если это так, я не вижу очень веской причины, чтобы зависимости разработчиков и одноранговых узлов вели себя по-разному в команде install

@bdwain @kyleholzinger Я не согласен, потому что peerDependencies строго предназначены для информирования о необходимости зависимости, а не для указания фактического действия по установке зависимости.

Это гарантирует, что проблема временных версий зависимостей, которые также существуют в корневом пакете / пакете верхнего уровня, не используется молча (и неправильно). Рассмотрим в качестве примера babel-core .

Недостаток поддержки здесь в контексте yarn - это возможность определять как одноранговый узел, так и dev dep, как описано здесь .

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

@hulkish Хотя я согласен с мнением, когда это будет пример, когда вы захотите объявить что-то как одноранговую зависимость, но не как зависимость разработчика?

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

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

@kyleholzinger

@hulkish Хотя я согласен с мнением, когда будет пример, когда вы захотите объявить что-то как одноранговую зависимость, но не как зависимость разработчика?

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

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

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

@hulkish

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

Полностью получите это! Хотя возникает вопрос: если что-то является зависимостью однорангового узла, но вам это не нужно для запуска вашего модульного теста или сборки, то почему у вас это как одноранговая зависимость?


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

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

Моя основная просьба / предложение / надежда-получить-одобрение-на-работу будет заключаться в том, что когда вы yarn install (не в производстве) в модуле, который имеет одноранговые зависимости в собственном package.json чтобы были установлены обе его зависимости разработчика _, а также_ его одноранговые зависимости. Это ключевое различие, прямо сейчас устанавливаются только зависимости разработчиков, поэтому вы должны объявить зависимости как зависимости разработчиков, так и зависимости одноранговых узлов.


@bdwain @hulkish

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

Я специально говорю о том, когда вы делаете yarn install при разработке модуля с одноранговыми зависимостями, а не когда вы добавляете модуль с одноранговыми зависимостями в другой проект.

@bdwain не совсем так, это определенно скользкая вещь для описания. Попробую привести пример:

Вариант использования с проблемой

Допустим, это ваш пакет верхнего уровня:

  "dependencies": {
    "foo": "^4.0.0",
    "react": "^15.0.0"
  }

затем ваш foo / package.json:

  "dependencies": {
    "react": "^16.0.0"
  }

Согласно этому дереву зависимостей, когда вы запускаете yarn / npm install, ваш каталог node_modules будет выглядеть так:

node_modules/
  react/ <-- @^15.0.0
  foo/node_modules/react/ <-- @^16.0.0

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

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

Пример использования решения peerDependencies

  "dependencies": {
    "foo": "^4.0.0",
    "react": "^15.0.0"
  }

затем ваш foo / package.json:

  "peetDependencies": {
    "react": "^16.0.0"
  }

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

Разница в этом варианте использования: Вместо этого проблема тихо существовала. Когда вы запускаете npm / yarn install - менеджер пакетов должен сообщать о несовместимости как об ошибке или предупреждении.

Надеюсь, это лучше объясняет.

@kyleholzinger

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

Я понимаю. Я думаю, что поведение по умолчанию для одноранговых подразделений должно оставаться как есть. Но я думаю, что простое решение - разрешить настройку с помощью cli и / или env vars и / или .yarnrc . Что-то вроде --install-peers-as-dev

@hulkish

Но я думаю, что простое решение - разрешить настраивать это через cli и / или env vars и / или .yarnrc. Что-то вроде --install-peers-as-dev

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

@kyleholzinger, это хорошее место для начала https://github.com/yarnpkg/yarn/blob/master/src/cli/commands/install.js#L58

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

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

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

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

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

В любом случае об этих предупреждениях / ошибках необходимо сообщать.

Как это возможно, что у нас еще нет этой функции? Я новичок в создании пакетов npm, но похоже, что это часть основного рабочего процесса разработки пакетов npm.

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

Я считаю эту особенность чрезвычайно важной.

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

Скажем, я хочу разработать библиотеку компонентов, которая имеет react и react-dom как peerDependencies (я не хочу, чтобы они в конечном итоге были объединены тем, кто ее использует, что будет дублировать эти две библиотеки и могут вызвать проблемы, с которыми я сталкивался раньше).

Я хочу протестировать свою библиотеку компонентов с установленными peerDependencies , поэтому я хотел бы запустить yarn --include-peerDeps (или что-то в этом роде) на CI и на моей машине, но когда кто-то запускает yarn в собственном пакете. Я хочу, чтобы они использовали свои собственные зависимости react и react-dom для запуска своих тестов (независимо от того, как они это делают).

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

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

Я рад обсудить и помочь с реализацией, если это необходимо.

@lucasfcosta не мог с этим согласиться! У меня нет кучи времени, чтобы поработать над этим в наши дни, поэтому я пытался ковыряться, когда могу, но, похоже, не могу получить правдивую опцию из опции командной строки. Хотел бы протянуть руку помощи :)

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

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

Мне это тоже нужно. Тем временем я выполнил небольшую задачу узла

const pkg = require('./package.json');
const entries = Object.entries(pkg.peerDependencies);
const shell = require('shelljs');

let deps = ['yarn add'];
for ([dep, version] of entries) {
    deps[deps.length] = `${dep}@${version}`;
}

deps.push('--peer');
const cmd = deps.join(' ');
console.log('Installing peer deps!\n -----', cmd);
const result = shell.exec(cmd);

if (result.code !== 0) {
    shell.echo('Error: installing peer dependencies');
    shell.exit(1);
}

Круто! Теперь мы можем просто вставить его в пряжу и добавить флаг или что-то еще.

Четверг, 4 октября 2018 г., 17:29 Паскуале Манджиалавори [email protected]
написал:

Мне это тоже нужно. Тем временем я выполнил небольшую задачу узла

`const pkg = require ('./ package.json');
константные записи = Object.entries (pkg.peerDependencies);
const shell = require ('shelljs');

let deps = ['пряжа добавить'];
for ([dep, version] записей) {
deps [deps.length] = $ {dep} @ $ {версия};
}

deps.push ('- сверстник');
константа cmd = deps.join ('');
console.log ('Installing peer deps! n -----', cmd);
const результат = shell.exec (cmd);

if (result.code! == 0) {
shell.echo ('Ошибка: установка зависимостей пира');
shell.exit (1);
} `

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/yarnpkg/yarn/issues/1503#issuecomment-427063046 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AE64MGxna2iQ-BFNiC52mIVro8sydPu1ks5uhilsgaJpZM4KiMuo
.

Я также использую подход дублирования, как сказал @RWOverdijk . Рад видеть эту функцию в будущем.

Кстати, есть ли у кого-нибудь лучшее решение, чтобы нам не нужно было добавлять один пакет дважды (devDependencies и peerDependencies)?

Привет из будущего. Это все еще проблема для разработчиков пакетов / библиотек. Повторяющиеся данные не должны быть ответом.

Я определенно хотел бы, чтобы эта функция была добавлена. Без добавления react в devDependencies моего пакета я не могу запускать тесты в своем коде.

Было бы неплохо установить флаг для установки пакетов в локальном объекте peerDependencies , но я также не вижу _ никаких_ недостатков в том, чтобы сделать установку _only_ local peerDependencies поведением по умолчанию. И семантически это имеет смысл, взаимные зависимости должны быть там, чтобы пакет работал везде, почему он должен быть другим локально?

Мое мнение об использовании флага было бы следующим из-за его соответствия
yarn add --peer команда.

yarn --peer
# and
yarn install --peer

По крайней мере, следует ввести флаг.

Интересно, хорошее ли решение здесь - использовать отдельное приложение test ? Затем вы можете добавить все свои peerDependencies как dependencies test . Кажется, это делает следующее:

  • сохраняет peerDependencies из devDependencies в вашей библиотеке
  • вы будете в некотором смысле e2e тестировать свою библиотеку ... чтобы убедиться, что ваш dist построен правильно, вы правильно экспортируете все свои компоненты и тому подобное
  • позволяет избежать случайной ошибки Invalid hook call когда вы забываете удалить node_modules из своего пакета при использовании локальных зависимостей, например "my-package": "file:/path/to/my-package"

Если людям будет полезна дополнительная информация, я создал демо-репозиторий, чтобы смоделировать этот подход и задокументировать проблему:
https://github.com/jamstooks/package-peer-dependencies

На данный момент вы должны иметь возможность запустить npx install-peerdeps <package> и затем интерфейс командной строки спросит вас, хотите ли вы использовать Yarn для установки, если у вас есть блокировка пряжи и т. Д. В папке. По крайней мере, сейчас это сработало для меня.

Дополнительные обсуждения от Arcanis («сбой установки на отсутствующих одноранговых серверах») и Isaac («установка одноранговых узлов автоматически») здесь, в этом RFC NPM:

https://github.com/npm/rfcs/pull/43

Это сообщение в блоге помогло мне с этой проблемой: https://dev.to/yvonnickfrin/how-to-handle-peer-dependencies-when-developing-modules-18fa

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

  "dependencies": {
    "prismic-reactjs": "^1.2.0"
  },
  "peerDependencies": {
    "react": "^16.12.0"
  },
  "devDependencies": {
    "react": "^16.12.0",
    "redux": "^4.0.5"
  }

Объяснение: мой пакет полагается на присутствие react во время выполнения и также нуждается в нем для тестирования. redux здесь для демонстрационных целей, см. Ниже.

Теперь prismic-reactjs также полагается на react как на свою одноранговую зависимость.
Что происходит после вызова yarn --production ?

React одновременно _installed_ и _hoisted_
Я ожидал, что ничего из двух не произойдет.

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

Репро репозитория: https://github.com/emirotin/yarn-react-repro . Запустите test.sh для быстрой проверки.

npm теперь имеет эту функцию с v7 ... по какой причине не добавить это в yarn?

@sajadghawami, насколько мне известно, у @arcanis есть довольно большие оговорки по поводу этого:

https://github.com/npm/rfcs/pull/43#issuecomment -520584797

Была ли эта страница полезной?
0 / 5 - 0 рейтинги