Yarn: Adicionar um meio de instalar dependências de pares de pacotes para desenvolvimento / teste

@ jpollard-cs Não estou me referindo a adicionar um pacote como dependência de mesmo nível, mas sim a ter um meio de instalar todos os pacotes atualmente listados como dependências de mesmo nível.
Caso contrário, não há um meio viável de desenvolver plug-ins.

npm install
Instalaria todos os pacotes declarados na seção de dependências do package.json.

yarn add --peer
Eu esperava que isso instalasse todos os pacotes declarados na seção package.json peerDependencies.

Existe uma maneira de instalar pacotes declarados em peerDependencies?

Meu caso de uso é o desenvolvimento / teste de um módulo nativo react.

Aqui está o problema do NPM, que eles fecharam: https://github.com/npm/npm/issues/11213

Aparentemente, não é importante para os desenvolvedores do NPM.

+1 isso é importante para os autores da biblioteca

Já escrevi isso sobre a questão do NPM, mas para o pessoal do Yarn:

Eu escrevi um programa cli para instalar as dependências de pares de um pacote:

# 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

Se você tiver algum problema com ele, abra um problema no repo!

@nathanhleung , esse pacote parece instalar todas as suas dependências, dependências de pares. O que não é exatamente sobre o que este bilhete se trata. Trata-se de instalar as dependências de pares do seu próprio pacote.

Eu consertei com um pacote para fazer isso https://www.npmjs.com/package/@team-griffin/install -self-peers

@nathanhleung, você é

Hmm ... Se alguém precisa de dependências para desenvolvimento / teste, não deveria colocá-las em devDependencies ? Não tentando jogar uma bomba nem nada ...

@nikolakanacki Para ver totalmente de onde você está vindo, acho que a estranheza é que seria tanto uma dependência de peer quanto uma dependência de dev, já que você nunca deve forçar seus consumidores a instalarem suas dependências de dev. Eu voto facilitando a instalação de pares!

@nikolakanacki Se você criar um pacote que depende de outro pacote instalado pelo usuário, não o quer em devDependencies, o que pode resultar em uma duplicação desse pacote em uma versão diferente. e não fará sentido em alguns casos. ...

Caso de uso eslint-find-rules

O pacote procura regras disponíveis no ESLint que não estão configuradas em sua configuração.
Para que faça sentido para um usuário, ele precisa verificar o pacote ESLint que ele instalou, e não alguma versão específica com a qual seu pacote vem (ou latest ).
Portanto, é uma dependência peer .

Agora, se você quiser contribuir com o projeto, você quer ter o ESLint instalado em node_modules para que possa testar seu código, sem fazer algum npm-link com um projeto fictício que instala ESLint.

Quando o usuário executa yarn , o sistema não deve instalar peer deps e avisar que estão faltando (isso funciona).

Então ... um sinalizador que torna o yarn install peer deps se eles ainda não estiverem instalados resolveria esse problema.

Ponto interessante

• yarn add <package> --peer instala em node_modules e o adiciona a package.json
• yarn add <other_package> depois disso remove o pacote instalado de node_modules

Atualmente, estou seguindo o modelo de @nikolakanacki e parece funcionar. Eu concordo que pode ser confuso e eu preferiria que yarn install --peer instalasse dependencies , devDependencies e peerDependencies mas isso funciona tão bem para mim.

Se estou entendendo corretamente @kyleholzinger / @gaastonsr , você não está tentando instalar peerDependencies no modo de desenvolvimento ( cd -ed no repositório / pacote que tem peerDependencies , clone fresco, precisa desenvolver nesses peer deps), mas adicioná-los ao projeto de destino depois de instalar o pacote que tem peer deps?

Para esclarecer: você instala eslint-find-rules que reclama que você precisa de eslint como uma dependência (é um peerDependency de eslint-find-rules ), então agora você quer uma maneira fácil de adicionar essas dependências no peer você está trabalhando (projeto atual que depende de eslint-find-rules )? Algo como "Resolver e adicionar como novas dependências (modificar package.json e yarn.lock ) dependências de pares que melhor correspondem às minhas dependências atuais"?

Se este for o seu ponto, poderia ser muito útil, pensei que você estava se referindo à instalação automática deles durante o desenvolvimento.

O recurso pode ser introduzido para mais do que pura conveniência, por exemplo: várias dependências podem depender do mesmo pacote do destino do par, mas exigem diferentes versões dele - esse recurso pode tirar o melhor proveito, tentando resolver para um único melhor -alvo de correspondência (se possível).

Algo em que pensar definitivamente.

Se este for o seu ponto, poderia ser muito útil, pensei que você estava se referindo à instalação automática deles durante o desenvolvimento.

É isso que estou procurando. Instalando peerDependencies quando estou desenvolvendo um pacote.

Sim, exatamente @nikolakanacki! Sinto que há uma grande oportunidade para ajudarmos as pessoas a gerenciar seus departamentos de pares.

@gaastonsr precisa adicioná-lo a devDependencies então - é tão simples quanto isso. Caso contrário, seu pacote está quebrado para desenvolvimento. Depois de clonar o projeto e executar yarn - tudo deve ser instalado e você deve ser capaz de executar testes, etc.

Duas perguntas simples e totalmente não relacionadas que devemos fazer antes de instalar a referida dependência em casos como este:

1. Meu pacote depende desse pacote, mas espero que o projeto de destino o inclua, pois meu pacote é apenas um plugin para esse pacote: Coloque-o em peerDependencies .
2. Tenho testes que dependem desse pacote, mas ele não está listado em meu dependencies (e não deveria estar listado lá) por qualquer motivo: Coloque-o em devDependencies .

Em outras palavras: Todos os pacotes que devem estar presentes durante o desenvolvimento e não são listados como uma dependência direta do pacote em desenvolvimento devem residir em devDependencies . Duplicatas não são um problema - em nenhum lugar da documentação afirma que enganações não são permitidas / encorajadas nesses casos.

@nikolakanacki Quando construímos um plugin para um pacote, devemos depender da versão do pacote instalado pelo usuário, se o adicionarmos como devDependency , iremos inevitavelmente instalar uma versão diferente e ela será usada em vez de a versão do usuário.

A menos que tenhamos definido a dependência como * , então o Yarn deve ser de alguma forma determinístico e preferir o pacote instalado pelo usuário ao invés do nosso.

Atualmente não é assim:

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

@alexilyaev Acho que @nikolakanacki significa instalá-lo como peerDependency e devDependency.

Isso tem o problema de que precisamos manter os dois sincronizados. Para mim funciona bem por enquanto, mas não acho que seja o ideal.

@alexilyaev quando você declara peerDependency você declara também sua versão. A menos que o projeto alvo tenha a versão dessa dependência de peer instalada que também satisfaça a versão que você definiu - yarn / npm reportará um erro (falta de dependência de peer, algo assim).

No entanto, devDependency não tem nada a ver com isso, é o que está sendo instalado ao executar yarn ou npm install dentro do pacote de origem (aquele que declara uma dependência de par, por exemplo : um plugin), e nem mesmo é consultado quando o pacote está sendo usado por um pacote / projeto de terceiros (um par).

A questão é: não vejo como tudo isso é relevante.

Eu posso ver a dor de mantê-los sincronizados, mas você poderia facilmente escrever um script bash / javascript / <whatever> que verificaria isso como uma etapa pós-instalação no package.json .

O que estou tentando mostrar é que de forma alguma devemos quebrar o sentimento devDependencies , ou pior ainda, introduzir "executar yarn ou npm install não necessariamente instala todos os dependências necessárias deste "conceito de pacote.

Por outro lado yarn introduziu uma política ainda mais rígida quando se trata disso, ela limpa os pacotes não definidos de outra forma como dependencies ou devDependencies para que você não execute em questões mais tarde.

@nikolakanacki Digamos que meu plug-in aceita ^7.0.0 e o último do par é 7.9.0 e o usuário definido em seu package.json 7.4.0 .
se eu terei ^7.0.0 em devDependencies também, o Yarn não instalaria (para o usuário) tanto 7.9.0 quanto 7.4.0 ?

Se isso acontecer, meu plugin pode erroneamente usar 7.9.0 instalado em vez de 7.4.0 .

@alexilyaev Seu pacote sempre usará, como qualquer outro pacote em qualquer outro caso, a versão mais alta disponível que satisfaça a "faixa semver" definida em seu pacote para este dep.

Eu seria mais específico, mas não entendi bem o caso que você apresentou, poderia esclarecer?

~ Irá avisá-lo de que você tem uma incompatibilidade de peerDependency , seu plugin espera ^7.0.0 e você tem a versão 7.4.0 . ~ Atualizado: ^7.0.0 satisfaz 7.4.0 .

o Yarn não instalaria (para o usuário) 7.9.0 e 7.4.0?

O Yarn não instala peerDependencies para você e não instala o devDependencies do seu plugin, apenas as dependências em dependencies .

@gaastonsr você está absolutamente certo, exceto que ^7.0.0 é satisfeito por 7.4.0 .

As dependências de mesmo nível nunca são instaladas, as dependências de desenvolvimento não são instaladas por padrão se o pacote não for o pacote principal. O "usuário final" precisa definir quais dependências de pares deseja satisfazer adicionando-as às "dependências" regulares do projeto, junto com o intervalo. Ele pode satisfazer ou não o "intervalo de sempre" que você precisa em seu plug-in, e o usuário será notificado sobre o último.

Intervalos de Semver explicados por npm: https://docs.npmjs.com/misc/semver
Em caso de dúvida, verifique sempre: http://jubianchi.github.io/semver-check/

@nikolakanacki para poder instalar facilmente os pacotes peerdependencies seria ótimo!

@nikolakanacki Ok, então, de fato, quando o usuário final instala o pacote, devDependencies não é instalado, então o autor do pacote deve adicionar peerDependencies a devDependencies também.

Então, isso resolve a questão do desenvolvimento local.

Mas, parece que muitos projetos não adicionaram a dependência de par como uma dependência de desenvolvimento.
Então, acho que devemos começar a espalhar a palavra e colocar os projetos a bordo.
Isso inevitavelmente levará a longas discussões sobre por que funcionou com o npm, mas não com o Yarn e, independentemente dos resultados, vai demorar um pouco e nem todos os projetos podem fazer a mudança.

Então ... Estou propondo ainda oferecer suporte a uma maneira de instalar dependências de mesmo nível, pelo menos para que não tenhamos que usar mais install-peerdeps .

Qual é o problema real aqui? Não parece que instalar uma lista de deps seria mais complicado do que instalar outra lista de deps. As dependências de pares existem há alguns anos. Como isso não incomodou ninguém?

A solução devDependencies configurado corretamente na biblioteca para testes isolados (fora de um projeto host que fornece o peerDependencies ) e você precisa de peerDependencies para testes integrados e para garantir o host projeto não termina com instalações de pacotes redundantes / duplicados porque as bibliotecas que ele consome estão usando o mesmo dependencies e _ não _ fazendo uso adequado de peerDependencies e devDependencies .

Existe a pequena dor de cabeça de mantê-los em sincronia. Mas, como @nikolakanacki apontou, isso poderia ser facilmente mitigado por meio de alguns scripts post-install .

Que solução?

Analisei os comentários rápido o suficiente e não percebi uma solução simples:

Sempre instale peerDependencies como dependências regulares, se estiver no pacote de nível superior

Ele se encaixa perfeitamente nos casos de desenvolvimento / teste e não afeta a instalação do pacote como dependência. Semelhante à lógica que temos para yarn.lock. Não há necessidade de "desenvolvimento" extra ou qualquer outro modo.

Na verdade, devido a outros bugs de fios relacionados a peerDependencies, parece exatamente como ele se comporta em alguns casos.

Concordo plenamente, se você executar 'yarn install' em um repo, ele deve instalar quaisquer dependências de peer que ainda não estejam listadas no dep. Eu realmente não vejo como isso é diferente das dependências de desenvolvimento nesse aspecto - se você estiver desenvolvendo nesse módulo, você _precisa_ que esses módulos sejam instalados

Estou encerrando isso porque não consigo ter uma imagem clara de qual é o problema e qual é a solução proposta, se houver.

Sinta-se à vontade para reabrir com um esclarecimento ou apresentar um novo bug.

@BYK tem certeza de que está fazendo a coisa certa ao encerrar questões com 55 polegares para cima e 34 comentários só porque não está claro para você?

Eu acho que é bastante simples: certifique-se de que peerDependencies estejam instaladas quando definidas no pacote de nível superior .
Ou vamos dizer de outra forma: trate peerDependencies como dependências regulares quando definidas no pacote atual

Adicionar dependências de mesmo nível também como dependências de desenvolvimento, conforme proposto mais adiante neste tópico, interromperá o fluxo digitado: https://github.com/flowtype/flow-typed/issues/379

@andvgal Estou apenas tentando resolver os problemas e toda a discussão aqui de meses atrás foi opressora e difícil de resumir.

Eu acho que é bastante simples: certifique-se de que peerDependencies estejam instaladas quando definidas no pacote de nível superior.
Ou vamos dizer de outra forma: trate peerDependencies como dependências regulares quando definidas no pacote atual

Este foi um ótimo resumo, obrigado. Reabrindo o problema, mas precisamos pensar com muito cuidado sobre as implicações de instalar peerDependencies por padrão, se decidirmos seguir esse caminho.

Ou - pelo menos - forneça uma maneira de instalar separadamente as dependências de pares sem tocar no arquivo package.json. Ao usar add para instalar uma dependência de par, a entrada no arquivo JSON é modificada. Se você configurou sua expressão semver de uma maneira diferente daquela que o yarn escreve por padrão, ela será alterada.

Acho que a ideia de adicionar um switch --peer para instalar é boa, mas na verdade eu gosto de poder instalá-los um por um, já que costumo vincular alguns desses módulos, e vou para frente e para trás entre um link e realmente ter o módulo instalado. Com o npm, posso apenas executar o 'npm i'. Em Yarn, não vejo um equivalente. Especificamente, quero poder instalar um arquivo, usando as especificações em package.json, sem modificar o arquivo package.json.

@jimsugg , tenho usado yarn add <package...> -p para instalar manualmente as dependências de mesmo nível já listadas no package.json, o que é definitivamente um antipadrão. Parece que as dependências de pares devem ser instaladas automaticamente em ambientes de desenvolvimento (se for de fato uma dependência de pares, então deve haver pelo menos testes exigindo o pacote).

Eu estava procurando a mesma coisa e vim com este Bash one-liner para instalar todos os peer deps listados (requer que você tenha o jq instalado): yarn add $(jq -r '.peerDependencies|keys|join(" ")' package.json) .

Espero que isto ajude alguém.

@EdwardDrapkin Obrigado por essa ideia lendária! Eu o estendi e acabei adicionando um script npm para fazer isso:

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

Apenas mantém a especificação de versão de peerDependencies também;) Só engate aqui depois é se você não quiser usar a tag latest , mas sim outra que você está trabalhando como next ou algo assim.

@shousper aqui está uma maneira sem a dependência 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 um cenário em que você não gostaria de instalar uma dependência de peer do pacote Foo quando está trabalhando diretamente em Foo ? Não consigo pensar em nenhum. Se Bar é necessário para usar Foo , você precisa dele ao trabalhar em Foo e, como é uma dependência de par, não pode ser uma dependência regular. Ele então teria que ser instalado apenas ao trabalhar diretamente no pacote, que é o que as dependências de desenvolvimento fazem.

Por causa disso, acho que faz sentido que o yarn trate as dependências de pares da mesma forma que as devDependências, mas também faça o que fazem agora, que é gerar avisos. Normalmente, apenas faço de cada dependência de peer uma devdependency, então isso economizaria alguma duplicação.

Existe um motivo para isso ser um problema? Provavelmente seria uma alteração significativa, então teria que esperar até 2.0, mas fora isso, parece que não teria problemas.

Um problema pode ser que você queira uma versão mais específica instalada para dev do que o requisito de seus pares. Nesse caso, eu diria que você deve ser capaz de substituir a versão de mesmo nível para instalações locais, duplicando-a em devDependencies. Por exemplo

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

Limitaria a instalação local do react a ~ 16.1.0, mas permitiria qualquer versão v16 como uma dependência de peer. Não tenho certeza de onde algo assim seria necessário, mas não parece inválido.

Eu concordo @bdwain , eu entendo semanticamente qual é a diferença entre um peer e uma dependência de dev, mas na prática eles são instalados exatamente da mesma maneira; se você estiver desenvolvendo o módulo, precisará instalar as dependências de desenvolvedor e de mesmo nível, e se estiver usando o módulo, instale apenas as dependências reais listadas. Se for esse o caso, não vejo um bom motivo para não ter as dependências de dev e de par se comportando de maneira diferente no comando install

@bdwain @kyleholzinger Eu discordo, porque peerDependencies tem o propósito estrito de informar a necessidade de uma dependência, não instruir a ação real de instalação da dependência.

Isso garante que o problema de versões de dependência temporária que também existem no pacote de nível raiz / superior não sejam silenciosamente (e incorretamente) sendo usados. Considere babel-core como exemplo.

O suporte que falta aqui no contexto do yarn é a capacidade de definir como um par e como um dev dep, conforme descrito aqui .

Dito isso, para se manter alinhado com a especificação de instalação padrão para peer deps e fornecer uma melhor experiência de desenvolvimento ... talvez o yarn pudesse introduzir uma opção --include-peers para o comando de instalação?

@hulkish Embora eu concorde com o sentimento, quando seria um exemplo quando você gostaria de declarar algo como uma dependência de par, mas _não_ como uma dependência de dev?

Se eu entendi o uso corretamente, especialmente com yarn, a lista de dependências de pares é sempre um subconjunto das dependências de dev. Se for esse o caso, acho que isso deve ser oficialmente reconhecido e você não precisa declarar dependências de mesmo nível como dependências de desenvolvimento.

A única razão pela qual menciono isso é porque acho que adicionar um comando / opção que adicionaria algo tanto como uma dependência de desenvolvedor quanto de par parece que aumentaria a complexidade do yarn em geral, e eu sinto que há uma solução em algum lugar que é legal e simples 😄

@kyleholzinger

@hulkish Embora eu concorde com o sentimento, quando seria um exemplo quando você gostaria de declarar algo como uma dependência de par, mas não como uma dependência de dev?

Quando você não precisa dele para seus testes de unidade ou.build para rodar. Pela minha experiência, para começar, essa é a única necessidade de adicioná-los nos dois lugares.

Acho que a solução aqui é o yarn apresentar uma opção que permite a instalação automática de pares. Lembre-se de que o principal benefício de usar peerDependencies é obter uma visão sobre quando dependências temporárias incompatíveis estão sendo usadas. A chave aqui é não quebrar o comportamento padrão de peer deps na instalação.

Acho que @hulkish estava falando sobre um cenário em que você depende de uma dependência de uma dependência para obter uma de suas dependências de mesmo nível. No entanto, não acho que isso causaria problemas, porque a dependência transitiva ainda precisaria corresponder ao intervalo especificado pela dependência de peer, que deve ser um intervalo grande de qualquer maneira. Se a dependência transitiva fosse mais específica do que a dependência do par, esse intervalo teria precedência e todos os requisitos ainda seriam satisfeitos.

@hulkish

Quando você não precisa dele para seus testes de unidade ou .build para executar

Consiga isso totalmente! Embora isso implique a questão: se algo é uma dependência de ponto, mas você não precisa disso para o seu teste de unidade ou compilação ser executado, então por que você o tem como uma dependência de ponto?

Lembre-se de que o principal benefício de usar peerDependencies é obter uma visão sobre quando dependências temporárias incompatíveis estão sendo usadas

Concordo plenamente com isso, acho que as dependências de pares são incríveis agora do consumidor do módulo que está declarando a dependência de uma biblioteca com dependências de pares. Minha principal queixa / problema é ao desenvolver em módulos que têm dependências de pares. Desculpe se houve alguma confusão!

Minha principal pergunta / sugestão / esperança-de-aprovação-para-trabalho seria quando você yarn install (não em produção) em um módulo que possui dependências de pares em seu próprio package.json que ambas as suas dependências dev _ assim como_ suas dependências de pares sejam instaladas. Essa é a principal diferença, no momento apenas as dependências de desenvolvimento são instaladas, então você deve declarar as dependências de desenvolvimento como dependências de desenvolvimento e dependências de pares.

@bdwain @hulkish

Eu acho que @hulkish estava falando sobre um cenário onde você depende de uma dependência de uma dependência para puxar uma de suas dependências de pares

Estou falando especificamente sobre quando você faz yarn install ao desenvolver um módulo com dependências de mesmo nível, não quando você adiciona um módulo com dependências de mesmo nível a outro projeto

@bdwain não exatamente, é definitivamente uma coisa escorregadia de descrever. Vou tentar usar um exemplo:

Caso de uso com problema

Digamos que este seja o seu pacote de nível superior:

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

então, seu foo / package.json:

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

De acordo com esta árvore de dependências, quando você executa yarn / npm install, seu diretório node_modules será semelhante a este:

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

Neste ponto, a menos que você (por qualquer motivo) decida inspecionar voluntariamente sua estrutura de dir aninhada node_modules - você nunca saberia que há um problema. Isso não é culpa do gerenciador de pacotes - ele completou seu trabalho com precisão.

Portanto, peerDependencies pretende resolver esse caso de uso tratando-os mais como uma verificação de validação em vez de uma instrução para instalar.

Caso de uso com solução peerDependencies

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

então, seu foo / package.json:

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

Primeiro, vamos deixar claro que, neste ponto, os dois casos de uso têm o mesmo problema de versões de reação incompatíveis entre si.

A diferença neste caso de uso é; Em vez deste problema existir silenciosamente. Quando você executa npm / yarn install - o gerenciador de pacotes tem a obrigação de relatar a incompatibilidade como um erro ou aviso.

Espero que isso explique melhor.

@kyleholzinger

Estou falando especificamente sobre quando você faz a instalação do yarn ao desenvolver um módulo com dependências de pares, não quando você adiciona um módulo com dependências de pares a outro projeto

Compreendo. Eu acho que o comportamento padrão para peer deps deve permanecer como está. Mas, acho que uma solução fácil é permitir que isso seja configurável via cli e / ou env vars e / ou .yarnrc . Algo como --install-peers-as-dev

@hulkish

Mas, acho que uma solução fácil é permitir que isso seja configurável via cli e / ou env vars e / ou .yarnrc. Algo como --install-peers-as-dev

Claro que sim! Pessoalmente, acho que eles não deveriam estar tanto nas dependências de desenvolvimento quanto nas dependências de pares, mas isso poderia ser uma discussão separada. Acho que adicionar essa opção seria um compromisso sólido e uma ótima maneira de resolver o problema enquanto isso - vou dar uma olhada e tentar fazer algo juntos :)

@kyleholzinger este é um bom lugar para começar https://github.com/yarnpkg/yarn/blob/master/src/cli/commands/install.js#L58

Além disso, encorajo em seu pr que, ao encaminhar peerDependencies para serem instaladas como dev, você queira ter certeza de que quaisquer avisos de compatibilidade ou erros ainda sejam relatados.

@hulkish eu entendo o que são dependências de pares. Meu ponto é que, na prática, você sempre precisa deles instalados para fins de desenvolvimento, portanto, eles devem ser tratados como devDependencies, além de sua função de avisar quando houver incompatibilidade de versões.

Se um pacote Foo tiver uma dependência de par no Bar, o único cenário em que você não gostaria que o Bar fosse instalado ao trabalhar diretamente no Foo seria se sua construção e os testes automatizados não precisassem do Bar. Mas se fosse esse o caso, isso significaria apenas que sua compilação / testes não exercitaram a funcionalidade que exigia a dependência de ponto no Bar em primeiro lugar, o que não deveria ser o caso comum.

Eu realmente não acho que uma opção para habilitar a instalação automática de dependências de pares seja a coisa certa a fazer porque isso seria necessário com mais freqüência do que não (a menos que você também especifique os pares como dependências de desenvolvimento, o que acaba com o ponto). Se uma opção for necessária com mais freqüência do que não, deve ser o padrão e deve haver uma opção para desativá-la. yarn install deve funcionar sem opções para os casos mais comuns, e precisar que dependências de mesmo nível sejam tratadas como dependências de desenvolvimento é o caso mais comum. Adicionar uma etapa extra para o usuário médio é apenas uma experiência pior.

E adicioná-los automaticamente ao dev e ao par ainda tem o problema de duplicar a dependência em dois lugares, o que é um problema e não deveria ser necessário.

De qualquer forma, esses avisos / erros precisam ser relatados.

Como é possível que ainda não tenhamos esse recurso? Eu sou novo na criação de pacotes npm, mas parece que faz parte do fluxo de trabalho principal de desenvolvimento de pacotes npm.

Mesmo @biels! Na verdade, esqueci totalmente que disse que iria trabalhar nisso, então ainda não comecei, vou tentar trabalhar nisso quando puder, para que possamos pelo menos colocar essa opção em .yarnrc e não precisa se preocupar com isso o tempo todo

Acho que esse recurso é extremamente importante.

Posso pensar em muitos casos de uso, especialmente quando se trata de autores de bibliotecas.

Digamos que eu queira desenvolver uma biblioteca de componentes que tenha react e react-dom como peerDependencies (não quero que sejam agrupados por quem quer que a use, isso seria essas duas bibliotecas e podem causar problemas, que já experimentei antes).

Quero testar minha biblioteca de componentes com aqueles peerDependencies instalados, então gostaria de executar yarn --include-peerDeps (ou algo parecido) no CI e na minha máquina, mas quando alguém executa yarn em seu próprio pacote Eu quero que eles usem suas próprias dependências react e react-dom para executar seus testes (não importa como eles façam isso).

Também acho que, como temos módulos por aí que fazem exatamente isso e têm muitos downloads, já justifica tornar esse recurso nativo. (O velho lema de "fazer algo que as pessoas querem" se aplica aqui IMO)

Não consigo ver como isso pode ser uma prática ruim, já que teria que ser alternado explicitamente entre --include-peerDeps .

Fico feliz em discutir e ajudar na implementação, se necessário.

@lucasfcosta não poderia estar mais de acordo! Não tenho muito tempo para trabalhar nisso atualmente, então tenho tentado vasculhar quando posso, mas não consigo encontrar a opção verdadeira na linha de comando. Adoraria uma mão amiga :)

@lucasfcosta aqui está minha implementação ruim de onde eu pensei que a opção poderia residir, mas não tenho ideia. Estava tentando seguir o padrão de algumas outras opções de linha de comando, mas não parecia funcionar.

No momento, estou adotando a abordagem de duplicação (devDependencies e peerDependencies), mas adoraria esse recurso, então posso parar de fazer isso.

Eu também preciso disso. entretanto, fiz uma pequena tarefa de nó

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

Legal! Agora podemos apenas colar no fio e adicionar uma bandeira ou qualquer outra coisa.

Em Qui, 4 de outubro de 2018, 17:29 Pasquale Mangialavori [email protected]
escrevi:

Eu também preciso disso. entretanto, fiz uma pequena tarefa de nó

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

deixe deps = ['yarn add'];
para ([dep, versão] de entradas) {
deps [deps.length] = $ {dep} @ $ {version};
}

deps.push ('- peer');
const cmd = deps.join ('');
console.log ('Instalando dependências de mesmo nível! n -----', cmd);
resultado const = shell.exec (cmd);

if (result.code! == 0) {
shell.echo ('Erro: instalação de dependências de mesmo nível');
shell.exit (1);
} `

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/yarnpkg/yarn/issues/1503#issuecomment-427063046 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AE64MGxna2iQ-BFNiC52mIVro8sydPu1ks5uhilsgaJpZM4KiMuo
.

Também estou adotando a abordagem de duplicação, como disse @RWOverdijk . Adoro ver esse recurso no futuro.

Aliás, alguém tem uma solução melhor para não precisarmos adicionar um pacote duas vezes (devDependencies e peerDependencies)?

Olá do futuro. Isso ainda é um problema para desenvolvedores de pacote / lib. Depósitos duplicados não deveriam ser a resposta.

Eu definitivamente gostaria de ver esse recurso adicionado. Sem adicionar react ao devDependencies meu pacote, não consigo executar testes no meu código.

Um sinalizador para instalar os pacotes no objeto peerDependencies seria bom, mas também não vejo _qualquer_ desvantagem em tornar a instalação _apenas_ local peerDependencies o comportamento padrão. E semanticamente faz sentido, as dependências de pares precisam estar lá para o pacote funcionar em qualquer outro lugar, por que seria diferente localmente?

Minha opinião sobre o uso de uma bandeira seria a seguinte por causa de seu alinhamento com o
Comando yarn add --peer .

yarn --peer
# and
yarn install --peer

No mínimo, a bandeira deve ser introduzida.

Eu me pergunto se usar um app test separado é uma boa solução aqui? Você pode então adicionar todos os seus peerDependencies como dependencies do aplicativo test . Isso parece fazer o seguinte:

• mantém peerDependencies de devDependencies em sua biblioteca
• você estará e2e testando sua biblioteca, de uma forma ... garantindo que seu dist foi construído corretamente, você está exportando todos os seus componentes corretamente e esse tipo de coisa
• evita o erro ocasional Invalid hook call quando você se esquece de limpar node_modules de seu pacote ao usar dependências locais, como "my-package": "file:/path/to/my-package"

Se mais informações fossem úteis para as pessoas, criei um repositório de demonstração em um esforço para modelar essa abordagem e documentar o problema:
https://github.com/jamstooks/package-peer-dependencies

Por enquanto, você deve ser capaz de executar npx install-peerdeps <package> e a CLI perguntará se você deseja usar o Yarn para a instalação, se você tem um bloqueio de fios, etc. na pasta. Pelo menos isso funcionou para mim agora.

Mais discussão de Arcanis ("falha na instalação em deps de pares ausentes") e Isaac ("instalar deps de pares automaticamente") aqui neste RFC de NPM:

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

Esta postagem do blog me ajudou com esse problema: https://dev.to/yvonnickfrin/how-to-handle-peer-dependencies-when-developing-modules-18fa

Eu tenho um problema relacionado, eu acho.
Para uma reprodução mínima, tenho esta lista de dependências:

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

Explicação: meu pacote depende da presença de react em tempo de execução e também precisa dele para teste. redux está aqui para fins de demonstração, veja abaixo.

Agora, prismic-reactjs também depende de react como sua dependência de pares.
O que acontece depois que yarn --production é chamado?

React está _instalado_ e _hoisted_
Eu esperaria que _nenhum_ dos dois acontecesse.

Para fins de demonstração, redux é adicionado aqui, que _não_ está instalado, o que (eu acho) prova que a dependência transitória de pares é a causa do problema.

Repro repo: https://github.com/emirotin/yarn-react-repro . Execute test.sh para a verificação rápida.

npm tem esse recurso agora com v7 ... alguma razão para não adicionar isso ao yarn?

@sajadghawami , até onde eu sei, @arcanis tem grandes reservas sobre fazer isso:

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