Yarn: Agregar un medio para instalar dependencias de pares de paquetes para desarrollo / prueba

@ jpollard-cs No me refiero a agregar un paquete como una dependencia de pares, me refiero a tener un medio para instalar todos los paquetes actualmente listados como dependencias de pares.
De lo contrario, no existe un medio viable para desarrollar complementos.

npm install
Instalaría todos los paquetes declarados en la sección de dependencias de package.json.

yarn add --peer
Esperaba que esto instalara todos los paquetes declarados en la sección package.json peerDependencies.

¿Hay alguna forma de instalar paquetes declarados en peerDependencies?

Mi caso de uso es el desarrollo / prueba de un módulo nativo de reacción.

Aquí está el problema de NPM, que cerraron: https://github.com/npm/npm/issues/11213

Aparentemente no es importante para los desarrolladores de NPM.

+1 esto es importante para los autores de bibliotecas

Ya escribí esto sobre el tema de la NPM, pero para la gente de Yarn:

Escribí un programa cli para instalar las dependencias de pares de un paquete:

# 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

Si tiene algún problema con él, abra un problema en el repositorio.

@nathanhleung , ese paquete parece instalar todas sus dependencias entre pares. De eso no se trata exactamente este boleto. Se trata de instalar las dependencias de pares de su propio paquete.

Lo he arreglado con un paquete para hacer eso https://www.npmjs.com/package/@team-griffin/install -self-peers

@nathanhleung eres

Hmm ... Si uno necesita dependencias para desarrollo / prueba, ¿no debería ponerlas debajo de devDependencies ? Sin intentar lanzar una bomba ni nada ...

@nikolakanacki Vea de dónde viene, creo que la rareza es que sería tanto una dependencia de pares como una dependencia de desarrollo, ya que nunca debe obligar a sus consumidores a instalar sus dependencias de desarrollo. ¡Voto para facilitar la instalación de compañeros!

@nikolakanacki Si

Caso de uso eslint-find-rules

El paquete busca reglas disponibles en ESLint que no están configuradas en su configuración.
Para que tenga sentido para un usuario, debe verificar el paquete ESLint que instalaron y no alguna versión específica con la que viene su paquete (o latest ).
Entonces, es una dependencia peer .

Ahora, si desea contribuir al proyecto, desea tener ESLint instalado en node_modules para que pueda probar su código, sin hacer ningún npm-link con un proyecto ficticio que instala ESLint.

Cuando el usuario ejecuta yarn , el sistema no debe instalar peer deps y advertir que faltan (esto funciona).

Entonces ... una bandera que haga que el hilo instale a los pares si aún no están instalados resolvería amablemente ese problema.

Punto interesante

• yarn add <package> --peer instala en node_modules y lo agrega a package.json
• yarn add <other_package> después de eso elimina el paquete instalado de node_modules

Actualmente sigo el modelo de yarn install --peer para instalar dependencies , devDependencies y peerDependencies pero esto funciona igual de bien para mí.

Si estoy haciendo esto bien @kyleholzinger / @gaastonsr , no está buscando instalar peerDependencies en modo de desarrollo ( cd -ed en el repositorio / paquete que tiene peerDependencies , clon nuevo, necesita desarrollar en esos departamentos de pares) pero agregarlos al proyecto de destino una vez que instale el paquete que tiene departamentos de pares?

Para aclarar: instala eslint-find-rules que se queja de que necesita eslint como dependencia (es un peerDependency de eslint-find-rules ), por lo que ahora desea una manera fácil de agregar esas dependencias en el peer que está trabajando (proyecto actual que depende de eslint-find-rules )? ¿Algo como "Resolver y agregar nuevas dependencias (modificar package.json y yarn.lock ) las dependencias de pares que mejor coincidan con las que requieren mis dependencias actuales"?

Si este es su punto, podría ser muy útil, pensé que se refería a instalarlos automáticamente al desarrollar.

La función podría introducirse para una mayor comodidad, por ejemplo: varias dependencias podrían depender del mismo paquete del objetivo del mismo nivel, pero requerirían diferentes versiones; esta función podría sacar el máximo provecho de ella tratando de resolver una única mejor -objetivo coincidente (si es posible).

Algo en lo que pensar definitivamente.

Si este es su punto, podría ser muy útil, pensé que se refería a instalarlos automáticamente al desarrollar.

Esto es lo que busco. Instalación de peerDependencies cuando estoy desarrollando un paquete.

¡Sí, exactamente @nikolakanacki! Siento que tenemos una gran oportunidad para ayudar a las personas a administrar sus departamentos de pares.

@gaastonsr necesita agregarlo a devDependencies entonces, es tan simple como eso. De lo contrario, su paquete está roto para el desarrollo. Una vez que clone el proyecto y ejecute yarn , todo debería estar instalado y debería poder ejecutar pruebas, etc.

Dos preguntas simples y totalmente desvinculadas que se deben hacer antes de instalar dicha dependencia en casos como este:

1. Mi paquete depende de este paquete, pero espero que el proyecto de destino lo incluya ya que mi paquete es solo un complemento para ese paquete: Ponlo en peerDependencies .
2. Tengo pruebas que dependen de este paquete, pero no aparece en mi dependencies (y no debería aparecer allí) por el motivo que sea: Ponlo en devDependencies .

En otras palabras: todos los paquetes que se espera que estén presentes durante el desarrollo y que no están listados como una dependencia directa del paquete que se está desarrollando deben residir en devDependencies . Los duplicados no son un problema; en ninguna parte de los documentos se indica que los incautos no están permitidos / recomendados en estos casos.

@nikolakanacki Cuando creamos un complemento para un paquete, debemos depender de la versión del paquete instalado por el usuario, si lo agregamos como devDependency , inevitablemente instalaremos una versión diferente y se usará en lugar de la versión del usuario.

A menos que definamos la dependencia como * , pero Yarn debería ser de alguna manera determinista y preferir el paquete instalado por el usuario en lugar del nuestro.

Actualmente no es así:

• https://github.com/yarnpkg/yarn/issues/3793
• https://github.com/yarnpkg/yarn/issues/3778

@alexilyaev Creo que @nikolakanacki significa instalarlo como peerDependency y devDependency.

Esto tiene el problema de que necesitamos mantener ambos sincronizados. Para mí funciona bien por ahora, pero no creo que sea ideal.

@alexilyaev cuando declaras un peerDependency también declaras su versión. A menos que el proyecto de destino tenga instalada la versión de esa dependencia de pares que también satisfaga la versión que definiste, yarn / npm informará un error (falta de dependencia de pares, algo así).

No menos devDependency no tiene nada que ver con eso, es el que se instala cuando se ejecuta yarn o npm install dentro del paquete fuente (el que declara una dependencia entre pares, por ejemplo : un complemento), y ni siquiera se consulta cuando el paquete está siendo utilizado por un paquete / proyecto de terceros (un par).

El punto es: no veo cómo todo esto es relevante.

Puedo ver el dolor de mantenerlos sincronizados, pero podría escribir fácilmente un script bash / javascript / <whatever> que verificaría esto como un paso posterior a la instalación en el package.json .

El punto que estoy tratando de hacer es que de ninguna manera debemos romper el sentimiento devDependencies , o peor aún, introducir "ejecutar yarn o npm install no necesariamente instala todos los dependencias requeridas de este concepto de paquete ".

Por otro lado yarn introdujo una política aún más estricta cuando se trata de esto, borra los paquetes que no están definidos de otra manera como dependencies o devDependencies para que no ejecute en problemas más adelante.

@nikolakanacki Digamos que mi complemento acepta ^7.0.0 y el último del par es 7.9.0 y el usuario definido en su package.json 7.4.0 .
si también tendré ^7.0.0 en devDependencies , ¿no instalaría Yarn (para el usuario) tanto 7.9.0 como 7.4.0 ?

Si lo hace, mi complemento podría usar por error el 7.9.0 instalado en lugar de 7.4.0 .

@alexilyaev Su paquete siempre, como cualquier otro paquete en cualquier otro caso, usará la versión más alta disponible que satisfaga el "rango semver" definido en su paquete para esta dep.

Sería más específico, pero no entiendo bien el caso que ha presentado, ¿podría aclararlo?

~ Le advertirá que tiene una incompatibilidad peerDependency , su complemento espera ^7.0.0 y tiene la versión 7.4.0 . ~ Actualizado: ^7.0.0 satisface 7.4.0 .

¿Yarn no instalaría (para el usuario) tanto 7.9.0 como 7.4.0?

Yarn no instala peerDependencies por usted y no instalará el devDependencies de su complemento solo las dependencias en dependencies .

@gaastonsr tiene toda la razón, excepto que ^7.0.0 está satisfecho con 7.4.0 .

Las dependencias de pares nunca se instalan, las dependencias de desarrollo no se instalan de forma predeterminada si el paquete no es el paquete principal. El "usuario final" necesita definir qué dependencias de pares desea satisfacer agregándolas a las "dependencias" regulares del proyecto, junto con el rango. Puede satisfacer o no satisfacer el "rango semver" que necesita en su complemento, y el usuario será notificado de esto último.

Rangos de Semver explicados por npm: https://docs.npmjs.com/misc/semver
En caso de duda, consulte siempre: http://jubianchi.github.io/semver-check/

¡Sería genial que

@nikolakanacki Ok, de hecho, cuando el usuario final instala el paquete, devDependencies no se instalan, por lo que el autor del paquete también debe agregar peerDependencies a devDependencies .

Entonces, esto resuelve el problema del desarrollo local.

Pero, parece que muchos proyectos no agregaron la dependencia de pares como una dependencia de desarrollo.
Así que supongo que deberíamos empezar a correr la voz e incorporar proyectos.
Esto inevitablemente conducirá a largas discusiones sobre por qué funcionó con npm pero no con Yarn, e independientemente de los resultados, llevará un tiempo y no todos los proyectos podrían hacer el cambio.

Entonces ... estoy proponiendo seguir admitiendo una forma de instalar dependencias entre pares, al menos para que no tengamos que usar install-peerdeps más.

¿Cuál es el problema real aquí? No parece que instalar una lista de departamentos sea más complicado que instalar otra lista de departamentos. Las dependencias entre pares existen desde hace algunos años. ¿Cómo no ha molestado esto a nadie?

La solución devDependencies configurar correctamente en la biblioteca para pruebas aisladas (fuera de un proyecto anfitrión que proporciona los peerDependencies ) y necesita peerDependencies para pruebas integradas y para asegurar el anfitrión El proyecto no termina con instalaciones de paquetes redundantes / duplicados porque las bibliotecas que consume están usando el mismo dependencies y _ no _ haciendo un uso adecuado de peerDependencies y devDependencies .

Existe el pequeño dolor de cabeza de mantenerlos sincronizados. Pero como @nikolakanacki señaló, esto podría mitigarse fácilmente mediante algunas secuencias post-install comandos de

¿Qué solución?

Revisé los comentarios lo suficientemente rápido y no noté una solución simple:

Instale siempre peerDependencies como dependencias regulares, si está en el paquete de nivel superior

Se adapta perfectamente a los casos de desarrollo / prueba y no afecta la instalación del paquete como dependencia. Similar a la lógica que tenemos para yarn.lock. No hay necesidad de un "desarrollo" adicional o de cualquier modo.

En realidad, debido a otros errores relacionados con peerDependencies, parece exactamente cómo se comporta en algunos casos.

Muy de acuerdo, si ejecuta 'yarn install' en un repositorio, debería instalar cualquier dependencia de pares que no esté listada en los departamentos. Realmente no veo en qué se diferencia de las dependencias de desarrollo en ese sentido; si está desarrollando en ese módulo, _necesita_ que estos módulos estén instalados

Estoy cerrando esto porque no puedo obtener una imagen clara de cuál es el problema y cuál es la solución propuesta, si la hay.

No dude en volver a abrir con una aclaración o presentando un nuevo error.

@BYK, ¿estás realmente seguro de que estás haciendo lo correcto al cerrar los problemas con 55 pulgares arriba y 34 comentarios solo porque no te queda claro?

Creo que es bastante sencillo: asegúrese de que peerDependencies estén instaladas cuando se establezcan en el paquete de nivel superior .
O digamos de otra manera: trate peerDependencies como dependencias regulares cuando se establezca en el paquete actual

Agregar dependencias de pares también como dependencias de desarrollo, como se propone más arriba en este hilo, romperá el tipo de flujo: https://github.com/flowtype/flow-typed/issues/379

@andvgal Solo estoy tratando de arreglar los problemas y toda la discusión aquí de hace meses fue abrumadora y difícil de resumir.

Creo que es bastante sencillo: asegúrese de que peerDependencies estén instaladas cuando se establezcan en el paquete de nivel superior.
O digamos de otra manera: trate peerDependencies como dependencias regulares cuando se establezca en el paquete actual

Este fue un gran resumen gracias. Reabriendo el problema, pero debemos pensar con mucho cuidado sobre las implicaciones de instalar peerDependencies de forma predeterminada si decidimos seguir ese camino.

O, al menos, proporcionar una forma de instalar por separado las dependencias de pares sin tocar el archivo package.json. Cuando se usa agregar para instalar una dependencia de pares, se modifica la entrada en el archivo JSON. Si ha configurado su expresión semver de una manera diferente a la que escribe yarn por defecto, se cambia.

Creo que la idea de agregar un interruptor --peer para instalar está bien, pero en realidad me gusta poder instalarlos uno por uno, ya que a menudo vinculo algunos de estos módulos, y voy y vengo entre un enlace y en realidad tener el módulo instalado. Con npm, puedo ejecutar npm i'. En Yarn, no veo un equivalente. Específicamente, quiero poder instalar un archivo, usando las especificaciones en package.json, sin modificar el archivo package.json.

@jimsugg , he estado usando yarn add <package...> -p , para instalar manualmente las dependencias de pares que ya figuran en package.json, que definitivamente es un anti-patrón. Parece que las dependencias entre pares deberían instalarse automáticamente en los entornos de desarrollo (si de hecho es una dependencia entre pares, al menos debería haber pruebas que requieran el paquete).

Estaba buscando lo mismo y se me ocurrió este resumen de Bash para instalar todos los departamentos de pares listados (requiere que tengas jq instalado): yarn add $(jq -r '.peerDependencies|keys|join(" ")' package.json) .

Espero que esto ayude a alguien más.

@EdwardDrapkin ¡ Gracias por eso, idea legendaria! Lo extendí y terminé agregando un script npm para hacer esto:

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

Solo mantiene la especificación de la versión de peerDependencies también;) Solo enganche aquí después si no desea usar la etiqueta latest , sino otra en la que esté trabajando como next o algo así.

@shousper aquí hay una forma sin la dependencia 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

¿Existe un escenario en el que no desee instalar una dependencia de pares del paquete Foo cuando esté trabajando directamente en Foo ? No puedo pensar en uno. Si se requiere Bar para usar Foo , lo necesita cuando trabaja en Foo , y dado que es una dependencia entre pares, no puede ser una dependencia regular. Entonces tendría que instalarse solo cuando se trabaja directamente en el paquete, que es lo que hacen las dependencias de desarrollo.

Por eso, creo que tiene sentido que yarn trate a peerDependencies de la misma manera que devDependencies, pero luego también haga lo que hacen ahora, que es generar advertencias. Por lo general, hago que cada dependencia de pares sea una dependencia de desarrollo, por lo que esto ahorraría algo de duplicación.

¿Hay alguna razón para que sea un problema? Probablemente sería un cambio importante, por lo que tendría que esperar hasta la versión 2.0, pero aparte de eso, parece que debería estar bien.

Un problema puede ser que desee que se instale una versión más específica para desarrolladores que los requisitos de sus pares. En ese caso, diría que debería poder anular la versión del mismo nivel para instalaciones locales duplicándola en devDependencies. Por ejemplo

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

Limitaría la instalación local de react to ~ 16.1.0, pero permitiría cualquier versión v16 como dependencia de pares. No estoy totalmente seguro de dónde sería necesario algo así, pero no parece inválido.

Estoy de acuerdo @bdwain , entiendo semánticamente cuál es la diferencia entre la dependencia de un par y un dev, pero en la práctica se instalan exactamente de la misma manera; Si está desarrollando el módulo, necesita instalar tanto las dependencias de desarrollo como las de los pares, y si está utilizando el módulo, solo debe instalar las dependencias reales enumeradas. Si ese es el caso, no veo una muy buena razón para que las dependencias de desarrolladores y pares no se comporten de manera diferente en el comando install

@bdwain @kyleholzinger No estoy de acuerdo, porque peerDependencies están estrictamente destinados a informar la necesidad de una dependencia, no a instruir la acción real de instalar la dependencia.

Esto garantiza que el problema de las versiones de dependencia transitoria que también existen en el paquete raíz / nivel superior no se utilice de forma silenciosa (e incorrecta). Considere babel-core como ejemplo.

El apoyo que falta aquí en el contexto del hilo es la capacidad de definir tanto como un compañero como un desarrollador, como se describe aquí .

Dicho esto, para mantenerse en línea con la especificación de instalación predeterminada para los departamentos de pares y brindar una mejor experiencia de desarrollo ... ¿tal vez Yarn podría introducir una opción --include-peers para el comando de instalación?

@hulkish Si bien estoy de acuerdo con el sentimiento, ¿cuándo sería un ejemplo en el que querría declarar algo como una dependencia de pares, pero _no_ como una dependencia de desarrollo?

Si entiendo el uso correctamente, especialmente con hilo, la lista de dependencias de pares es siempre un subconjunto de las dependencias de desarrollo. Si este es el caso, entonces creo que esto debería ser reconocido oficialmente y no debería ser necesario declarar las dependencias de pares como dependencias de desarrollo.

La única razón por la que menciono eso es que creo que agregar un comando / opción que agregaría algo tanto como dependencia de desarrollo como de pares parece que aumentaría la complejidad del hilo en general, y siento que hay una solución en algún lugar que es agradable y simple 😄

@kyleholzinger

@hulkish Si bien estoy de acuerdo con el sentimiento, ¿cuándo sería un ejemplo en el que querría declarar algo como una dependencia de pares, pero no como una dependencia de desarrollo?

Cuando no lo necesite para que se ejecuten sus pruebas unitarias o .build. Según mi experiencia, esta es en realidad la única necesidad de agregarlos en ambos lugares, para empezar.

Creo que la solución aquí es que Yarn introduzca una opción que permita la instalación automática de pares. Tenga en cuenta que el beneficio principal de usar peerDependencies es obtener una visión sobre cuándo se están usando dependencias transitorias incompatibles. La clave aquí es no romper el comportamiento predeterminado de los peer deps en la instalación.

Creo que @hulkish estaba hablando de un escenario en el que confías en una dependencia de una dependencia para atraer una de tus dependencias de pares. Sin embargo, no creo que esto cause ningún problema porque la dependencia transitiva aún necesitaría coincidir con el rango especificado por la dependencia entre pares, que de todos modos tiene que ser un rango grande. Si la dependencia transitiva fuera más específica que la dependencia entre pares, ese rango tendría prioridad y aún se cumplirían todos los requisitos.

@hulkish

Cuando no lo necesita para sus pruebas unitarias o .build para ejecutar

¡Consíguelo totalmente! Aunque eso plantea la pregunta: si algo es una dependencia entre pares, pero no lo necesita para que se ejecute su prueba unitaria o compilación, ¿por qué lo tiene como dependencia entre pares?

Tenga en cuenta que el beneficio principal de usar peerDependencies es obtener una visión sobre cuándo se usan dependencias transitorias incompatibles

Estoy totalmente de acuerdo con esto, creo que las dependencias entre pares son increíbles en este momento desde el consumidor del módulo que declara la dependencia en una biblioteca con dependencias entre pares, mi principal queja / problema es cuando se desarrolla en módulos que tienen dependencias entre pares. ¡Perdon si hubo alguna confusión!

Mi principal pregunta / sugerencia / esperanza-de-obtener-aprobación-para-trabajar sería que cuando yarn install (no en producción) en un módulo que tiene dependencias de pares en su propio package.json que se instalen tanto sus dependencias de desarrollo _ como_ sus dependencias de pares. Esa es la diferencia clave, en este momento solo se instalan las dependencias de desarrollo, por lo que debe declarar a los departamentos como dependencias de desarrollo y dependencias de pares.

@bdwain @hulkish

Creo que @hulkish estaba hablando de un escenario en el que confías en una dependencia de una dependencia para atraer una de tus dependencias de pares.

Estoy hablando específicamente de cuando haces yarn install al desarrollar un módulo con dependencias entre pares, no cuando agregas un módulo con dependencias entre pares a otro proyecto

@bdwain no exactamente, definitivamente es algo resbaladizo de describir. Intentaré usar un ejemplo:

Caso de uso con problema

Digamos que este es su paquete de nivel superior:

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

luego, tu foo / package.json:

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

Según este árbol de dependencias, cuando ejecuta yarn / npm install, su directorio node_modules se verá así:

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

En este punto, a menos que usted (por cualquier motivo) decida inspeccionar voluntariamente la estructura de directorios anidados de node_modules, nunca sabrá que hay un problema. Esto no es culpa del administrador de paquetes: completó su trabajo con precisión.

Por lo tanto, peerDependencies está destinado a resolver este caso de uso tratándolos más como una verificación de validación en lugar de una instrucción para instalar.

Caso de uso con la solución peerDependencies

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

luego, tu foo / package.json:

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

Primero, aclaremos que en este punto ambos casos de uso tienen el mismo problema de que las versiones de reacción son incompatibles entre sí.

La diferencia en este caso de uso es; En lugar de que este problema exista silenciosamente. Cuando ejecuta npm / yarn install, el administrador de paquetes tiene el deber de informar la incompatibilidad como un error o advertencia.

Espero que esto lo explique mejor.

@kyleholzinger

Estoy hablando específicamente de cuándo se instala yarn cuando se desarrolla un módulo con dependencias entre pares, no cuando se agrega un módulo con dependencias entre pares a otro proyecto

Entiendo. Creo que el comportamiento predeterminado para los departamentos de pares debería permanecer como está. Pero, creo que una solución fácil es permitir que esto sea configurable a través de cli y / o env vars y / o .yarnrc . Algo como --install-peers-as-dev

@hulkish

Pero, creo que una solución fácil es permitir que esto se pueda configurar a través de cli y / o env vars y / o .yarnrc. Algo como --install-peers-as-dev

¡Oh sí! Personalmente, creo que no deberían estar en dependencias de desarrollo y dependencias de pares, pero esa podría ser una discusión separada. Creo que agregar esta opción sería un compromiso sólido y una excelente manera de resolver el problema mientras tanto, lo revisaré e intentaré armar algo :)

@kyleholzinger, este es un buen lugar para comenzar https://github.com/yarnpkg/yarn/blob/master/src/cli/commands/install.js#L58

Además, recomiendo en su pr que, mientras reenvía peerDependencies para que se instalen como dev, desee asegurarse de que se sigan informando las advertencias o errores de compatibilidad.

@hulkish Entiendo qué son las dependencias entre pares. Mi punto fue que, en la práctica, siempre los necesita instalados para fines de desarrollo, por lo que deben tratarse como devDependencies además de su función de dar advertencias cuando las versiones no coinciden.

Si un paquete Foo tiene una dependencia de pares en Bar, el único escenario en el que no querría que Bar se instalara cuando trabajara directamente en Foo sería si su compilación y pruebas automatizadas no necesitaran Bar. Pero si ese fuera el caso, eso solo significaría que su compilación / pruebas no ejercieron la funcionalidad que requería la dependencia de pares en Bar en primer lugar, lo que no debería ser el caso común.

Realmente no creo que una opción para habilitar la instalación automática de dependencias entre pares sea lo correcto porque se necesitaría con mucha frecuencia (a menos que también haya especificado pares como dependencias de desarrollo, lo que anula el punto). Si se necesita una opción la mayoría de las veces, debería ser la predeterminada y debería haber una opción para deshabilitarla. yarn install debería funcionar sin opciones para los casos más comunes, y la necesidad de que las dependencias de pares se traten como dependencias de desarrollo es el caso más común. Agregar un paso adicional para el usuario promedio es simplemente una experiencia peor.

Y agregarlos automáticamente tanto al desarrollador como a los pares todavía tiene el problema de duplicar la dependencia en dos lugares, lo que en mi opinión es un problema y no debería ser necesario.

De cualquier manera, se deben informar esas advertencias / errores.

¿Cómo es posible que aún no tengamos esta función? Soy nuevo en la creación de paquetes npm, pero parece que es parte del flujo de trabajo principal del desarrollo de paquetes npm.

¡Lo mismo @biels! De hecho, olvidé por completo que dije que iba a trabajar en esto, así que aún no he comenzado, intentaré trabajar en eso cuando pueda para que al menos podamos hacer que la gente ponga esta opción en un .yarnrc y no tienes que preocuparte por eso todo el tiempo

Creo que esta característica es extremadamente importante.

Puedo pensar en muchos casos de uso, especialmente cuando se trata de autores de bibliotecas.

Digamos que quiero desarrollar una biblioteca de componentes que tenga react y react-dom como peerDependencies (no quiero que quienes la usen eventualmente los empaqueten, eso duplicaría esas dos bibliotecas y podrían causar problemas, que he experimentado antes).

Quiero probar mi biblioteca de componentes con esos peerDependencies instalados, así que me gustaría ejecutar yarn --include-peerDeps (o algo así) en CI y en mi máquina, pero cuando alguien ejecuta yarn en su propio paquete Quiero que utilicen sus propias dependencias react y react-dom para ejecutar sus pruebas (no importa cómo lo hagan).

También creo que, dado que tenemos módulos que hacen exactamente esto y tienen muchas descargas, ya se justifica que esta característica sea nativa. (El viejo lema de "hacer algo que la gente quiera" se aplica aquí en mi opinión)

No veo cómo esto podría ser una mala práctica ya que tendría que alternarse explícitamente entre --include-peerDeps .

Estoy feliz de discutir y ayudar con la implementación si es necesario.

¡@lucasfcosta no podría estar más de acuerdo! No tengo mucho tiempo para trabajar en él estos días, así que he estado tratando de hurgar cuando puedo, pero parece que no puedo obtener la opción de verdad desde la opción de línea de comandos. Aunque me encantaría una mano amiga :)

@lucasfcosta aquí está mi mala implementación de dónde pensé que podría vivir la opción, aunque no tengo idea. Estaba tratando de seguir el patrón de un par de otras opciones de la línea de comandos, pero no parecía funcionar.

Actualmente estoy tomando el enfoque de duplicación (devDependencies y peerDependencies) pero me encantaría mucho esta función para poder dejar de hacerlo.

Yo también lo necesito. mientras tanto, he hecho una pequeña tarea de nodo

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);
}

¡Frio! Ahora podemos pegarlo en hilo y agregar una bandera o lo que sea.

El jueves 4 de octubre de 2018 a las 17:29 Pasquale Mangialavori [email protected]
escribió:

Yo también lo necesito. mientras tanto, he hecho una pequeña tarea de nodo

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

let deps = ['agregar hilo'];
para ([dep, versión] de entradas) {
deps [deps.length] = $ {dep} @ $ {versión};
}

deps.push ('- par');
const cmd = deps.join ('');
console.log ('Instalando peer deps! n -----', cmd);
resultado constante = shell.exec (cmd);

if (result.code! == 0) {
shell.echo ('Error: instalando dependencias entre pares');
shell.exit (1);
} `

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/yarnpkg/yarn/issues/1503#issuecomment-427063046 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AE64MGxna2iQ-BFNiC52mIVro8sydPu1ks5uhilsgaJpZM4KiMuo
.

También estoy adoptando el enfoque de duplicación como dijo @RWOverdijk . Me encantará ver esta función en el futuro.

Por cierto, ¿alguien tiene una solución mejor para que no necesitemos agregar un paquete dos veces (devDependencies y peerDependencies)?

Hola desde el futuro. Esto sigue siendo un problema para los desarrolladores de paquetes / lib. Deps duplicados no debería ser la respuesta.

Definitivamente me gustaría ver esta función agregada. Sin agregar react a mi paquete de devDependencies , soy incapaz de ejecutar las pruebas en mi código.

Una bandera para instalar los paquetes en el objeto local peerDependencies estaría bien, pero tampoco veo _ ninguna_ desventaja en hacer que la instalación _only_ local peerDependencies el comportamiento predeterminado. Y semánticamente tiene sentido, las dependencias entre pares deben estar ahí para que el paquete funcione en cualquier otro lugar, ¿por qué sería diferente localmente?

Mi opinión sobre el uso de una bandera sería la siguiente debido a su alineación con el
yarn add --peer comando.

yarn --peer
# and
yarn install --peer

Como mínimo , debería introducirse la bandera.

Me pregunto si usar una aplicación test separada es una buena solución aquí. A continuación, puede agregar todos sus peerDependencies como dependencies de la aplicación test . Esto parece hacer lo siguiente:

• mantiene peerDependencies fuera de devDependencies en su biblioteca
• estará probando e2e su biblioteca, de alguna manera ... asegurándose de que su dist esté construido correctamente, esté exportando todos sus componentes correctamente y ese tipo de cosas
• evita el error ocasional Invalid hook call cuando se olvida de borrar node_modules de su paquete cuando usa dependencias locales, como "my-package": "file:/path/to/my-package"

Si más información sería útil para la gente, creé un repositorio de demostración en un esfuerzo por modelar este enfoque y documentar el problema:
https://github.com/jamstooks/package-peer-dependencies

Por ahora, debería poder ejecutar npx install-peerdeps <package> y la CLI le preguntará si desea usar Yarn para la instalación, si tiene un bloqueo de hilo, etc. en la carpeta. Al menos eso funcionó para mí en este momento.

Más discusión de Arcanis ("fallar la instalación en departamentos de pares faltantes") e Isaac ("instalar departamentos de pares automáticamente") aquí en este RFC de NPM:

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

Esta publicación de blog me ayudó con este problema: https://dev.to/yvonnickfrin/how-to-handle-peer-dependencies-when-developing-modules-18fa

Creo que tengo un problema relacionado.
Para la reproducción mínima tengo esta lista de dependencias:

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

Explicación: mi paquete se basa en la presencia de react en tiempo de ejecución y también lo necesita para realizar pruebas. redux está aquí para fines de demostración, consulte a continuación.

Ahora, prismic-reactjs también se basa en react como su dependencia de pares.
¿Qué sucede después de llamar a yarn --production ?

React está _instalado_ y _hoisted_
Esperaría que no sucediera ninguno de los dos.

Para fines de demostración, redux se agrega aquí, que no está instalado, lo que (creo) demuestra que la dependencia transitoria de los pares es la causa del problema.

Repro repositorio: https://github.com/emirotin/yarn-react-repro . Ejecute test.sh para la verificación rápida.

npm tiene esta característica ahora con v7 ... ¿alguna razón para no agregar esto al hilo?

@sajadghawami hasta donde yo sé, @arcanis tiene grandes reservas sobre hacer esto:

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