Não acho que seja um bug. Consegui reproduzir o problema, mas a diferença foi

52,55d51
< ansi-regex@*:
<   version "3.0.0"
<   resolved "https://registry.yarnpkg.com/ansi-regex/-/ansi-regex-3.0.0.tgz#ed0317c322064f79466c02966bddb605ab37d998"
<
1352c1348
< imurmurhash@*, imurmurhash@^0.1.4:
---
> imurmurhash@^0.1.4:

Essa alteração é apenas uma otimização do arquivo de bloqueio e não altera a semântica. Estamos planejando adicionar um aviso quando o arquivo de bloqueio precisar de uma atualização ao executar yarn install mas se você quiser garantir que seu arquivo de bloqueio permaneça o mesmo e seja preciso, você deve usar a opção --frozen-lockfile .

Tenho que admitir que isso não é intuitivo e estamos tentando encontrar uma boa solução para isso. Você pode acompanhar ou contribuir com a discussão em # 4147.

Se você concorda que isso não é um bug e # 4147 é um bom lugar para continuar a discussão, por favor, encerre o problema :)

@BYK obrigado por sua resposta atenciosa. Depois de ler o nº 4147, estou em dúvida sobre o encerramento desta edição. Espero que um pouco mais de discussão aqui possa ajudar.

4147 parece ser exclusivamente sobre o caso em que yarn.lock e package.json não estão em sincronia - na verdade, a única vez que a otimização é mencionada é neste comentário: https://github.com/yarnpkg/yarn/issues/4147 #issuecomment -321894341 - e esse comentário toca no assunto que me preocupa: yarn modificando o arquivo yarn.lock quando nenhuma mudança foi feita em package.json .

Parece-me que o arquivo yarn.lock só deve mudar se minhas dependências estiverem mudando de alguma forma. Na verdade, até este ponto, tenho dito aos meus desenvolvedores que, se eles virem uma alteração no arquivo yarn.lock , é hora de executar yarn install . Com as atualizações recentes, vários relataram que depois de receberem minhas alterações e executarem yarn install , seu arquivo de bloqueio mudou (a otimização). Isso torna a situação confusa - eles deveriam cometer a mudança? Devo pré-otimizar o arquivo de bloqueio de alguma forma (isso é possível)?

Parece que terei que, em curto prazo, adicionar --frozen-lockfile true a .yarnrc em todos os meus repos - mas não sou um grande fã dessa solução porque ela impede o fluxo de trabalho mencionado em # 4147 onde você edita package.json e então executa yarn install .

A intenção é que qualquer invocação de fio possa modificar yarn.lock ?

@BYK Lamento incomodá-lo com isso, porque sei que você está muito ocupado - mas espero obter uma resposta definitiva sobre isso. Meu fluxo de trabalho para distribuir mudanças de dependência para minha equipe evoluiu para este:

yarn add [blah]
rm -r node_modules yarn.lock
yarn install
rm -r node_modules
yarn install

Isso parece atualizar o arquivo de bloqueio corretamente (consulte # 4476) e, em seguida, otimiza o arquivo de bloqueio para que meus colegas de equipe não verifiquem as alterações do arquivo de bloqueio.

Minha equipe está usando o fio incorretamente? Devemos esperar que o arquivo de bloqueio mude a cada comando install ?

@artlogic IMHO, seus companheiros de equipe devem ter permissão para verificar as alterações do arquivo de bloqueio, mesmo que sejam apenas otimizações. Eu concordaria com a noção de que yarn install otimizar o arquivo de bloqueio é contra-intuitivo, mas ainda é algo que cada desenvolvedor de sua equipe pode comprometer com segurança. Não entendo por que você deseja proibir isso.

Dito isso, seu fluxo de trabalho pode levar a efeitos colaterais inesperados, pois você está quase desistindo das versões bloqueadas. Excluir o arquivo de bloqueio significa que o yarn tem que resolver todas as versões de dependências novamente, e ele tentará buscar a versão mais atual conforme apontado em seu package.json levando a uma possível quebra, esp. se mais de uma dependência for interrompida ao mesmo tempo em uma versão futura.

Se você ainda deseja garantir que a instalação não toque o arquivo de bloqueio, então você deve usar o sinalizador frozen-lockfile :

 yarn add {blah}

Verifique o arquivo de bloqueio e, em seguida, outro dev usaria:

   yarn install --frozen-lockfile

NÃO ADICIONE --frozen-lockfile a true em .yarnrc pois isso impede que você atualize, consulte: # 4570

Se você deseja atualizar suas dependências, execute:

 yarn upgrade

Se você deseja atualizar apenas uma dependência:

  yarn upgrade {blah}

Você também pode simplesmente instalar uma versão específica de uma dependência:

  yarn install {blah}@1.5

Isso permite um ajuste mais preciso e menos dores de cabeça a longo prazo.

@ k0pernikus - obrigado pela sua resposta detalhada. Em primeiro lugar, devo me desculpar por misturar dois problemas - o nº 4476 está impulsionando parte do meu fluxo de trabalho. O fato de que yarn upgrade parece estar um pouco quebrado não tem nada a ver com esse problema, é claro.

Quanto ao fluxo de trabalho, não consigo imaginar que a minha equipe seja a única em que um desenvolvedor é responsável por manter / testar novas dependências enquanto os outros desenvolvedores trabalham na base de código. O grande problema que tenho com o que começou a acontecer é que eu instalaria / testaria novas dependências, diria a todos para executar yarn install e, em seguida, obter 4-5 perguntas sobre se o yarn.lock alterado deve ser confirmado . Parece que eu estaria em um lugar pior se dissesse "se o arquivo de bloqueio mudar, envie-o" porque, nesse ponto, eu poderia acabar em um bloqueio de confirmação parecido com este:

• yarn.lock alterado (dev4)
• yarn.lock alterado (dev3)
• yarn.lock alterado (dev2)
• yarn.lock alterado (dev1)
• Dependências atualizadas (eu)

No entanto, pode ser que esta seja apenas a maneira como o yarn deve funcionar, então para os projetos da minha equipe, vamos mudar todos os nossos repositórios para usar lockfile congelado, de modo que apenas add e upgrade causem o arquivo de bloqueio para alterar.

Um cenário adicional ... parece que isso pode ser um aborrecimento potencial para projetos com muitos contribuidores, porque potencialmente cada vez que eles clonam e instalam, o arquivo de bloqueio pode mudar. Eu certamente não gostaria dessas otimizações em solicitações pull. A intenção é que a maioria dos projetos FOSS também usem a transição do yarn para um lockfile congelado?

@artlogic Nossa equipe tem --install.pure-lockfile true no projeto .yarnrc exatamente por este motivo.

@jboler - Eu não tinha visto essa configuração antes. Vou ter que dar uma olhada, mas parece que vou sugerir que adicionemos isso a .yarnrc para todos os nossos repositórios, e todos os repositórios de quaisquer projetos FOSS que eu tenha.

Se alguém da equipe do yarn puder confirmar que a intenção é que yarn install pode e irá alterar o arquivo de bloqueio em cada execução (apesar de nenhuma alteração nas dependências), então encerrarei este problema.

@artlogic desculpe pela resposta tardia.

O fato é que __espera-se__ que yarn install altere potencialmente o arquivo de bloqueio. Eu sei que isso não é ideal e precisa de uma melhor comunicação. Eu realmente quero ter um padrão melhor, mas enquanto isso, acho que algo como @jboler sugerido com, mas talvez usando --frozen-lockfile vez disso, seria a melhor solução até descobrirmos como o fio deve se comportar em diferentes cenários, como para fluxos de trabalho em que as pessoas preferem simplesmente editar package.json para atualizar as dependências em vez de usar yarn add etc.

@BYK Eu concordo com @artlogic . Este comportamento é muito confuso:

O grande problema que tenho com o que começou a acontecer é que eu instalaria / testaria novas dependências, diria a todos para executar a instalação do yarn e, em seguida, obteria 4-5 perguntas sobre se o yarn.lock alterado deve ser confirmado.

Nossa equipe consiste em aproximadamente 50 pessoas que administram yarn install todos os dias :(

@vkrol você deve ser capaz de fazer check-in de um arquivo .yarnrc que tenha --install.frozen-lockfile true ou --install.pure-lockfile true para evitar problemas até que o Yarn mude seu comportamento. Isso ajudaria?

@BYK pure-lockfile nos ajudará, mas não frozen-lockfile . Se bem entendi, yarn install falhará com um erro se frozen-lockfile estiver habilitado. Este comportamento é absolutamente inaceitável em nosso caso.

@vkrol minha preferência é frozen-lockfile uma vez que irá falhar apenas se o seu arquivo de bloqueio precisar ser alterado e não for consistente. Com pure-lockfile você pode ter um arquivo de bloqueio quase inútil ou muito impreciso, mas ainda assim não terá uma falha. O Yarn simplesmente usaria as resoluções internas que calculou com alegria. Se todos os membros da sua equipe usarem exatamente a mesma versão do Yarn, não haverá problema. Do contrário, pode ser perigoso.

@BYK talvez eu não entenda o comportamento de frozen-lockfile corretamente. Ele falha quando o lockfile é consistente com o conteúdo package.json, mas alguma otimização interna é necessária?

@vkrol não deve falhar quando o arquivo pode ser otimizado ainda mais, mas é consistente com package.json e é consistente em si mesmo. Se não, isso é um bug. Existe até um teste para isso: https://github.com/yarnpkg/yarn/blob/0415b07b3293ab125a77f3f66fe14034d6e5b376/__tests__/commands/install/lockfiles.js#L72 -L84

@BYK Eu não sabia disso. Vou tentar essa opção, obrigado! Acho que esse fato deve ser documentado em algum lugar.

@BYK

não deve falhar quando o arquivo pode ser otimizado ainda mais, mas é consistente com package.json e é consistente em si mesmo.

Eu encontrei algumas desvantagens no uso desta bandeira. Se yarn.lock pode ser otimizado, então as invocações repetidas deste comando yarn install --frozen-lockfile não são otimizadas através da verificação de "integridade" como sem este sinalizador. É um bug? Eu preciso criar o problema separado?

@BYK Obrigado pela sua resposta. Para os projetos da minha equipe, agora estamos usando frozen-lockfile e as coisas estão funcionando (relativamente) bem. Esta questão permanece bastante preocupante para mim, no entanto. Especificamente, as otimizações desnecessárias que o yarn está fazendo no arquivo de bloqueio ao executar yarn install .

Aqui está o exemplo mais claro que posso dar de onde esse comportamento causa problemas:

1. Eu adiciono uma nova dependência usando yarn add [blah] e confirmo meus package.json atualizados e yarn.lock .
2. Os contribuidores do meu pacote baixam as alterações e percebem que yarn.lock foi atualizado e, portanto, executam yarn install .
3. Em alguns casos, esses contribuidores acabam com yarn.lock modificado após a instalação. O que eles devem fazer neste caso? É uma corrida para ver quem pode enviar a solicitação pull primeiro?

Para ser claro, não tenho nenhum problema em yarn install modificar yarn.lock se package.json foi modificado. Meu problema é a otimização quando package.json não foi alterado. Vejo três soluções possíveis:

1. Direcione qualquer projeto que gerencie dependências centralmente para adicionar --install.frozen-lockfile true a um arquivo .yarnrc . Isso provavelmente seria um monte de projetos - a maioria dos pacotes NPM, eu acho.
2. Fornece uma opção para forçar o yarn para otimizar o arquivo de bloqueio durante a fase de adição, por exemplo, yarn add --optimize [blah] . Em seguida, instrua os mantenedores do pacote a sempre usarem essa opção.
3. Proibir a otimização de yarn.lock durante a fase de instalação, a menos que package.json pareça ter sido atualizado.

Estou defendendo a opção 3, mas também posso ver a opção 2 como uma escolha razoável.

Obrigado pelo seu tempo!

Eu meio que gosto da ideia de que yarn install não atualiza o arquivo yarn.lock mas em vez disso emite um aviso dizendo que "Seu arquivo yarn.lock está desatualizado, execute yarn blah para atualize-o agora.

@BYK por que ~ não ~ o yarn aplica otimizações a yarn.lock em yarn install vez de quando add / upgrade são executados?

editar: corrigir erro de digitação

@ spencer-brown: com base no que vi, ele realmente aplica otimizações na instalação - isso é o que considero problemático

A otimização para yarn.lock não deveria ser executada no yarn add? yarn.lock vai mudar de qualquer maneira. Esta é a opção número dois no comentário recente de @artlogic , certo? Por que a otimização não ocorre então, para que ninguém mais precise fazer outra alteração no yarn.lock?

@artlogic oops, typo :) - meu comentário deveria dizer "does"; editado.

Usamos muito o compositor e composer install nunca toca no arquivo de bloqueio.

composer update ou composer require (equivalente a yarn add ) deve ser executado para quaisquer alterações ou otimizações a serem feitas no arquivo de bloqueio.

Em muitos anos, nunca tivemos que nos preocupar com o comportamento ambíguo de composer install .

Sei que o fio preenche uma função um pouco diferente, mas o compositor tem o problema equivalente de atualizações manuais feitas em composer.json e ele fica fora de sincronia com o arquivo de bloqueio. Atualmente, composer install irá ignorar completamente o arquivo composer.json e emitir um aviso.

Usamos muito o compositor e composer install nunca toca no arquivo de bloqueio.

composer update ou composer require (equivalente a yarn add ) deve ser executado para quaisquer alterações ou otimizações a serem feitas no arquivo de bloqueio.

Em muitos anos, nunca tivemos que nos preocupar com o comportamento ambíguo de composer install .

Sei que o fio preenche uma função um pouco diferente, mas o compositor tem o problema equivalente de atualizações manuais feitas em composer.json e ele fica fora de sincronia com o arquivo de bloqueio. Atualmente, composer install irá ignorar completamente o arquivo composer.json e emitir um aviso.

Olá, crianças, o arquivo de bloqueio nunca deve ser alterado nas instalações subsequentes. é simplesmente idiota. se achar que vale a pena tocá-la na otimização, basta criar um arquivo separado que não entre no controle de versão.

Tal como acontece com o Gemfile.lock do Bundler, o ponto principal do yarn.lock é que sempre que a instalação do yarn for executada, você pode garantir resultados determinísticos em todos os ambientes. Se o yarn install alterar o arquivo de bloqueio, você perderá essa garantia. Outros comandos, como yarn add ou yarn update, obviamente devem alterar o yarn.lock, mas o yarn install não. Nossa equipe encontrou problemas em que temos versões de pacotes ligeiramente diferentes instaladas em ambientes diferentes, o que é exatamente o que não queremos.

Estou inclinado a pensar que yarn install --pure-lockfile deve ser o padrão e pode haver uma opção --fix-my-dev-process-inconsistencies-for-me-magically para obter o comportamento atual.

@ryancastle --pure-lockfile não informa que uma atualização é para o seu arquivo de bloqueio. Só não gera um. Isso ainda pode levar a um comportamento inesperado. --frozen-lockfile falhará se uma atualização for necessária.

Tenho operado com --install.frozen-lockfile true no meu .yarnrc há algum tempo e parece funcionar de maneira sã. O truque é criar o yarn.lock para o repo sem esse sinalizador em vigor. Depois de criado, as instalações não podem alterar o yarn.lock , mas as atualizações podem. Assim que comecei a usar este fluxo de trabalho, o número de alterações acidentais em yarn.lock caiu para zero.

@artlogic Sidenote: Eu costumava ter frozen-lockfile true em meu .yarnrc também, agora só aplico isso no servidor de compilação, pois encontramos problemas que eram alterações intencionais no yarn.lock não foram feitos, por exemplo, ao tentar sincronizar um package.json alterado com o yarn.lock , porque um desenvolvedor editou manualmente o package.json ou usou o npm para adicionar dependências.

Veja: https://github.com/yarnpkg/yarn/issues/4570

O caso de uso de @ k0pernikus é porque não tornamos --frozen-lockfile o padrão com yarn install . Sinceramente, não sei o que seria um bom compromisso sem prejudicar as pessoas que editam package.json e executam yarn install para atualizar o arquivo de bloqueio. Eu propus uma bandeira ou um novo comando como yarn sync mas a ideia precisa ser concretizada e então julgada pela comunidade antes de ser implementada.

Além disso, essa seria uma alteração importante, então exigiria o Yarn 2.x :)

uma bandeira ou um novo comando como yarn sync

parece bom para mim 👍. e yarn install poderia mostrar um aviso "package.json e yarn.lock estão fora de sincronia. Execute 'yarn sync' para atualizar o arquivo de bloqueio"

Sinceramente, não sei qual seria um bom compromisso sem atrapalhar as pessoas que editam o package.json e depois executam o yarn install para atualizar o lockfile.

Eu acho que em um determinado ponto uma decisão precisa ser tomada como qual é o fluxo de trabalho apropriado. Para mim, habilitar isso quase parece encorajar um antipadrão.

Eu propus uma bandeira ou um novo comando como o yarn sync, mas a ideia precisa ser concretizada e então avaliada pela comunidade antes de ser implementada.

Para mim, isso parece um compromisso razoável. Se você insiste em editar manualmente o seu package.json , então executar um comando para sincronizar as coisas faz sentido.

Aqui está o que eu gostaria de ver:

• yarn install sem um yarn.lock cria o yarn.lock .
• yarn install com yarn.lock não o modifica. Se ele encontrar uma discrepância entre yarn.lock e package.json um erro será retornado (como @indeyets indicado).
• yarn sync (ou talvez yarn install -s ) faz com que yarn.lock volte a sincronizar com package.json .

Ainda tenho uma preocupação subjacente de que yarn install modifique yarn.lock mesmo quando package.json não está fora de sincronia com o arquivo de bloqueio. Você verá acima que ele realiza algumas "otimizações". Seria possível pelo menos desativar esse comportamento sem uma alteração significativa?

Ainda tenho uma preocupação subjacente de que a instalação do yarn modifique o yarn.lock mesmo quando o package.json não está fora de sincronia com o arquivo de bloqueio. Você verá acima que ele realiza algumas "otimizações". Seria possível pelo menos desativar esse comportamento sem uma alteração significativa?

O mesmo sentimento aqui. Achei que esse era o motivo específico para esse problema permanecer aberto. Como a "sincronização" está sendo discutida em # 4147

É por isso que procurei esse problema em primeiro lugar.

Devemos mesclar isso e # 4147?

@BYK Acho que quase tudo o que foi discutido aqui pode ser mesclado com # 4147. Como eu disse antes, acho que a única coisa que ainda me preocupa são as "otimizações" que yarn install realiza em yarn.lock mesmo quando nenhuma mudança ocorreu em package.json .

Meu pensamento é que, como um paliativo no caminho para o yarn 2.0, essas otimizações devem ser desativadas. Eu não acho que isso seria uma mudança significativa.

Eu concordo 100% com @artlogic .

Eu estava configurando o CircleCI e minha construção continuava falhando e eu rastreei tudo até um problema de cache com yarn.lock . Vindo do Rails, eu esperaria que o arquivo de bloqueio fosse bloqueado por um comando de instalação.

Isso é o que está sendo sugerido para verificação de cache no CircleCI: https://circleci.com/docs/2.0/yarn/

#...
      - restore_cache:
          name: Restore Yarn Package Cache
          keys:
            - yarn-packages-{{ checksum "yarn.lock" }}
      - run:
          name: Install Dependencies
          command: yarn install
      - save_cache:
          name: Save Yarn Package Cache
          key: yarn-packages-{{ checksum "yarn.lock" }}
          paths:
            - ~/.cache/yarn
#...

Isso nunca funcionará porque yarn.lock pode mudar, quando não deveria.

Para sua informação, no yarn 1.10.1 no macOS 10.13.6, acabei de experimentar o estímulo de bug do OP e descobri que yarn.lock não foi alterado. Em outras palavras, quando tentei:

yarn init
yarn add cordova
cp yarn.lock yarn.lock.initial
rm -r node_modules
yarn install
diff yarn.lock.initial yarn.lock

Portanto, ao usar o yarn 1.10.1, o yarn install não mudou yarn.lock , como aconteceu com o OP ao usar o yarn 1.0.1. (Eu considero isso uma coisa boa, como acho que o OP.)

@dtgriscom Que bom que o problema não está mais acontecendo com Cordova! Estou me perguntando se ele foi corrigido totalmente ou se o yarn ainda pode tentar otimizar o arquivo de bloqueio na instalação.

Seria bom saber, não é? Você observou que o problema era específico do pacote; faz sentido que também seja específico da versão. (Nunca ouvi uma justificativa para "queremos mudar algo que não deveria mudar"; além de "estamos otimizando" ...)

Eu concordo plenamente que uma operação install precisa ser determinística por padrão. Atualizar um arquivo .lock deve exigir que o desenvolvedor execute uma ação que ele sabe que produzirá uma mudança no arquivo. Por exemplo, você poderia executar algo como yarn install --optimize que permitiria uma pequena otimização que não quebraria o estado atual dos pacotes.

Adicionar opções separadas que preciso consultar na documentação apenas para ter a certeza de que meu arquivo de bloqueio não foi alterado sem minha permissão é muito confuso, especialmente se elas podem causar falhas. Como desenvolvedor, espero ter controle sobre as ferramentas que uso e sinto que esse comportamento tira isso de mim.

Por favor, reconsidere inverter o comportamento padrão para não modificar o arquivo de bloqueio e operar somente nele ao instalar dependências. Uma verificação de integridade com um aviso de que package.json está fora de sincronia com o arquivo de bloqueio é realmente tudo que as pessoas precisam.

Tenho dito às pessoas que os PRs incluindo alterações no arquivo de bloqueio não serão mesclados, pois o arquivo de bloqueio só é alterado ao adicionar novas dependências ou atualizar. Isso é o que afirma a documentação de instalação :

yarn install

Instale todas as dependências listadas em package.json na pasta local node_modules .

O arquivo yarn.lock é utilizado da seguinte maneira:

• Se yarn.lock estiver presente e for suficiente para satisfazer todas as dependências listadas em package.json , as versões exatas registradas em yarn.lock serão instaladas e yarn.lock permanecerão inalteradas . O Yarn não verificará se há versões mais recentes.
• Se yarn.lock estiver ausente ou não for suficiente para satisfazer todas as dependências listadas em package.json (por exemplo, se você adicionar manualmente uma dependência a package.json ), o Yarn procura o versões mais recentes disponíveis que satisfazem as restrições em package.json . Os resultados são gravados em yarn.lock .

Se você quiser garantir que yarn.lock não seja atualizado, use --frozen-lockfile .

A documentação está errada, pois existem essas otimizações que podem acontecer mencionadas acima ou isso é um bug a levar em consideração por enquanto?

ps. ainda acontece, e yarn --frozen-lockfile não falha quando isso acontece.

No momento, estou usando --frozen-lockfile em meu arquivo .yarnrc , o que evita efetivamente que o yarn modifique o arquivo yarn.lock ao executar yarn install em máquinas diferentes. Mas isso também evita que yarn add blahblah modifique meu yarn.lock. Esse é o comportamento correto ou estou faltando alguma coisa? Eu li todo o tópico e me parece que --frozen-lockfile é a abordagem recomendada por enquanto?

@konekoya Sim, você está certo de que atualmente DEVE usar

yarn install --frozen-lockfile

e não pode confiar na configuração de .yarnrc pois isso impedirá que seu yarn.lock seja atualizado.

Dependendo do seu conteúdo de .npmrc e .yarnrc você pode usar

yarn install --no-default-rc {dependency}

mas eu não confiaria nisso (uma vez que quebraria assim que você tivesse outras configurações em seus arquivos rc).

Veja meu comentário e a questão relevante: # 4570, esp. minha conclusão .

Obrigado por esclarecer isso @ k0pernikus. Você fez meu dia :)

@BYK, por que o yarn aplica otimizações a yarn.lock em yarn install vez de quando add / upgrade são executados?

Acho que o comentário de @ spencer-brown aqui é a chave para "consertar" esse problema. Acabei de testar por mim mesmo e executando yarn upgrade e, em seguida, yarn Disseram-me "Já atualizado.". Então eu apaguei meu node_modules e executei yarn que resultou no lockfile "otimizado" que os outros desenvolvedores em meu projeto teriam terminado se eu tivesse empurrado aquele que obtive de yarn upgrade .

Agora, se yarn upgrade (e yarn add ) executassem a mesma otimização de yarn install , não teríamos esse problema em primeiro lugar. Tem havido muita conversa sobre não querer quebrar nenhuma funcionalidade existente e não vejo a execução da otimização após yarn upgrade e yarn add como algo quebrado - apenas tornando-o um pouco mais lento.

Como solução alternativa, estou pensando em instruir todos os nossos desenvolvedores a excluir node_modules sempre que precisarem atualizar o arquivo de bloqueio para forçar a "otimização" antes de enviar os arquivos de bloqueio para outros. Ou talvez eles possam executar yarn upgrade && yarn prune - talvez isso bastasse?

Como solução alternativa, estou pensando em instruir todos os nossos desenvolvedores a excluir node_modules sempre que precisarem atualizar o arquivo de bloqueio para forçar a "otimização" antes de enviar os arquivos de bloqueio para outros. Ou talvez eles possam executar yarn upgrade && yarn prune - talvez isso bastasse

Atualização: Você não pode executar o prune manualmente, você apenas recebe esta mensagem: _ "O comando prune não é necessário. yarn install irá remover pacotes estranhos" ._ E já que você também não pode executar a instalação porque você estão _ "Já atualizados" _ Acho que vamos deletar os node_modules e então executar yarn para fazer a poda.

Para mim, o maior argumento de venda de yarn é o comportamento previsível e confiável de arquivos de bloqueio. Alterar o arquivo de bloqueio em yarn install me causa uma ansiedade real.

Para mim, o maior argumento de venda de yarn é o comportamento previsível e confiável de arquivos de bloqueio. Alterar o arquivo de bloqueio em yarn install me causa uma ansiedade real.

O arquivo de bloqueio é apresentado como uma especificação exata do que será instalado, para que não tenhamos que nos preocupar com o que será instalado. Use o mesmo arquivo de bloqueio e você obterá a mesma instalação todas as vezes. Mas às vezes yarn irá, por sua própria iniciativa, por suas próprias razões, e sem aviso, alterar o conteúdo do arquivo de bloqueio. Sim, você pode argumentar que "as alterações no arquivo não alteram o que será instalado", mas por que aceitar uma garantia tão clara e bagunçar tudo? Por que me pergunto se devo comprometer novamente o arquivo de bloqueio alterado? Por que manchar sua principal reivindicação à fama?

Isso é realmente inacreditável. Outros já o afirmaram bem. Um arquivo de bloqueio não deve ser alterado na instalação. Isso afeta negativamente os fluxos de trabalho de confirmação. Cada desenvolvedor em nossa equipe sabe sob quais circunstâncias o arquivo de bloqueio pode ser alterado. Quando um arquivo de bloqueio é alterado sem que as dependências sejam atualizadas, isso causa confusão desnecessária e verificação extra. Este é o UX do gerenciador de pacotes básico que acabou de ser quebrado. Por favor conserte.

Fiquei surpreso com este comportamento, ao passar do Node.js 13 para 14, todos os meus yarn.lock arquivos mudaram ao fazer um yarn install e eu estava me perguntando por que ...

Acho que o comportamento apropriado seria emitir um aviso se _optimizando_ o arquivo yarn.lock alguma forma.