<p>o yarn provavelmente não deveria armazenar pacotes em cache resolvidos com um caminho de arquivo</p>

Isso também me enganou. Deve haver uma maneira de contornar isso sem limpar todo o cache.

Eu acho que poderia haver três maneiras de tornar o fio utilizável para este caso:

1. sugestão de @donaldpipowitch de ignorar todas as dependências locais.
2. Reinstalar dependências locais se um arquivo for modificado depois de quando foi armazenado em cache. Isso exigiria que guardássemos esses metadados. Para dependências locais, podemos inserir linhas como esta na coluna "Resolvido": file://<path>@<cache_timestamp>
3. Ignorar pacotes por nomes de pacotes com comandos como yarn cache rm <package> e yarn cache add <package> . Para todas as dependências.

Gostaria de ver a segunda sugestão a ser implementada. A menos que a terceira opção também possa ser útil para outros casos. Por exemplo, yarn cache add <package> pode ser usado para atualizar o cache de dependências já armazenadas em cache, caso algo possa dar errado durante o download de uma dependência.

@hantuzun, por que armazenar em cache as dependências locais? eles são locais de qualquer maneira, então serão rápidos independentemente de serem armazenados em cache ou não.

@ satya164 você está certo. Embora eu esteja mais inclinado para a terceira abordagem ajudaria se uma dependência da rede for modificada intencionalmente.

Algo como yarn cache ignore <package> será útil. Mas acho que eles não precisam ser mutuamente exclusivos. Ignorar um pacote é útil, mas requer trabalho manual. As dependências de arquivo poderiam funcionar sem nenhum esforço adicional se fossem ignoradas por padrão.

Alguém pode me explicar a lógica interna?

Meu entendimento:
Quando uma dependência com file: é encontrada, file-resolver.js entra em ação. Diz que a dependência deve ser copiada e não é hash . Nenhum hash significa que não deve ser armazenado em cache ...? Mas o copy-fetcher.js parece definir o hash para uma string vazia em vez de manter null ... É este o problema?

@bestander ou @kittens Talvez você possa explicar isso um pouco mais ...? Adoraria receber uma ajudinha para criar um PR ♥

Hash significa o hash md5 que é usado para o tarball-fetcher, por exemplo.
Esse hash é então adicionado ao arquivo yarn.lock para verificações futuras e também anexado ao nome da pasta ao salvar a pasta descompactada no cache.
Você está indo na direção certa, obrigado por investigar isso. Um RP é muito bem-vindo.
Você provavelmente pode começar com um PR que adiciona testes de unidade quebrados

Você provavelmente pode começar com um PR que adiciona testes de unidade quebrados

Ok, obrigado pela sua resposta. Devo enviar um ping para você como revisor no PR ou devo pingar para outra pessoa (ou para ninguém) ...?

Sim, me manda um ping

@bestander provavelmente este problema não deve ser resolvido, pois ainda não foi corrigido?

Sim, deve ser reaberto. Ele foi fechado porque escrevi "correções # 2165" no título do meu PR. No começo eu pensei que seria um PR contínuo, mas para corrigir esse bug queremos dois PRs: o primeiro adicionou um teste de unidade (a afirmação que falharia não é realmente ativa, então o CI não explode) e o o segundo vai realmente consertar.

Desculpe, o github fecha problemas quando PR é mesclado

então, obviamente, isso ainda é um problema? é muito chato de desenvolver, para ser honesto. está causando uma pequena perturbação para mim em um nível pessoal no trabalho, onde estou fazendo uso de file: para criar um ambiente de desenvolvimento modular. a parte ruim é que cada pacote local que eu edito (usando o caminho file: em package.json ), requer isso, a fim de puxar para baixo o conteúdo atualizado:

editar o conteúdo do meu pacote eslint-config-base-eslint

yarn cache clean && rm -rf node_modules/eslint-config-base-eslint && yarn install --force && yarn lint

Todos são bem-vindos para contribuir com o projeto.
Pode ser qualquer coisa - enviar um teste de integração quebrado para este caso, uma correção ou convencer alguém a trabalhar na correção.
Se você quiser conversar sobre a melhor maneira de abordar isso, pode encontrar ajuda no canal de discórdia.

Na verdade, acho que a correção deve ser de 10-15 linhas de código, provavelmente economizará muito tempo corrigindo-a mais cedo

Para sua informação: pode ser que esse problema também seja relevante para linking dependencies passos lentos. Veja meu comentário aqui: https://github.com/yarnpkg/yarn/issues/1496#issuecomment -282688818.

Desculpa. Não consegui encontrar tempo para criar outro PR para este problema :( Eu estava (e ainda estou) muito ocupado.

@bestander Este é um grande bloqueador para mim, trabalhando em um projeto de vários módulos. Se estou lendo os links de código e comentários de @donaldpipowitch corretamente, poderíamos fazer o resolvedor de arquivos criar um novo hash (em vez de nulo) toda vez que tentar resolver e forçar uma reinstalação? Diga um UUID ou carimbo de data / hora atual? Perdoe-me se algo estiver faltando, não estou familiarizado com o funcionamento do código.

Um novo cache com um registro de data e hora e uuid parece um hack razoável.
O ideal é copiar os arquivos diretamente sem o cache, mas pode ser um
mudança mais complexa.
Vá em frente, envie um PR

Na terça - feira, 7 de março de 2017 às 03:38, Matt Traynham

@bestander https://github.com/bestander Este é um bloqueador bem grande
para mim, trabalhando em um projeto multi-módulo. Se estou lendo @donaldpipowitch
https://github.com/donaldpipowitch links de código e comentários
corretamente, podemos fazer com que o resolvedor de arquivos crie um novo hash (em vez de
null) toda vez que ele tenta resolver então força uma reinstalação? Diga um UUID
ou carimbo de data / hora atual? Me perdoe se estou faltando alguma coisa, não estou familiarizado
com a forma como o código funciona.

-
Você está recebendo isso porque foi mencionado.

Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/yarnpkg/yarn/issues/2165#issuecomment-284612526 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/ACBdWDS3xSr8KNu1o9Zn8sA9xdO8pyHOks5rjNEmgaJpZM4LFbmf
.

@bestander Sobre seu último comentário: Não faria ainda mais sentido criar um link simbólico, em vez de copiar os arquivos? Ou há alguma razão para não fazer isso?

@danrot windows parece exigir que o administrador faça o link simbólico.
também bagunça recursivamente para encontrar módulos de nós

Symlink também ignora .npmignore e coisas assim. (O que atualmente parece ser ignorado também. O que pode ser problemático: https://github.com/yarnpkg/yarn/issues/1496#issuecomment-282688818)

Existe alguma solução alternativa para esse impedimento de limpar todo o cache? Infelizmente, parece não haver nenhum comando yarn cache rm package kind-of.

@ rhys-e eu uso este pequeno script:

#!/bin/sh
if [ $# != 1 ]
then
   echo Usage $0 package-name
   exit 1
else
    echo Reinstalling $1
fi

dir="node_modules/$1"

if [ -d $dir ]
then
    rm -fr $dir
fi

cache=`yarn cache dir`/npm-${1}*
#        echo $cache
rm -fr $cache && yarn install --force

Alguém tentou apenas yarn link todas as dependências locais de postinstall ? Parece a solução apropriada até que o conserto apropriado seja feito.

Acho que a ideia é não ter que atualizar o número da versão do pacote a cada mudança nas dependências locais. Um elo de fio o forçaria a fazer isso, certo? (não tentei)

Do meu lado, o que finalmente fiz foi invocar um script na fase de pré-instalação que compara o que está na pasta de origem e na pasta node_modules para dependências locais. Se detectar alguma diferença, ele apenas remove a dependência do cache e remove o arquivo de integridade (para forçar uma reinstalação). Portanto, quando não há mudanças, a instalação do yarn é muito rápida (não há muitas dependências locais) e, se houver, a versão em cache desatualizada não é usada.

O link

Eu testei diferentes combinações para contornar as mudanças no pacote local que não estava sendo atualizado na versão instalada do projeto pai em ./node_modules/. Acho que isso bastaria, sem a necessidade de excluir os ./node_modules/primeiro:

yarn cache clean; yarn upgrade file:../<package>

Desnecessário dizer que forçar manualmente a limpeza do cache global não deve ser necessário para atualizar / atualizar pacotes locais.

@fungilation Como solução alternativa, você também pode usar o npm para instalar dependências locais e, assim, evitar perder o cache inteiro sempre que desejar uma atualização.

Por # 2860 e o subsequente commit de mesclagem https://github.com/yarnpkg/yarn/commit/7241de13bb236526fa439a2528fbed319f60ef24 , agora você pode "atualizar" file: dependências de protocolo com

yarn install --force

Edite ou atualize o pacote específico (não percebi que isso funcionou também). Se a versão das dependências não mudou, isso não modifica o lockfile, mas ainda irá copiar a versão mais recente.

yarn upgrade [file protocol package name]

A mudança de PR invalidará a dependência no cache e o reinstalará localmente. yarn install também funcionará se a versão das dependências for alterada, o que invalida o arquivo yarn.lock. Você não precisa mais limpar o cache, nem excluir o módulo da instalação local.

Também ficou claro para mim que existe um RFC ativo para vincular dependências, possivelmente com um protocolo link: . Isso pode ser seguido aqui, https://github.com/yarnpkg/rfcs/pull/34.

@mtraynham Obrigado por sua solicitação de pull! 👌 Isso é incrível. Algum motivo para --force ser necessário? Eu atualmente nem sei o que ele faz exatamente agora sem procurar :) Apenas perguntando, porque o npm não precisa de um sinalizador --force e teria sido bom se comportar como o npm.

Editar Parece que yarn upgrade [dependency] funciona. Quero ressaltar que isso nem sempre altera o arquivo de bloqueio, que deve refletir apenas as alterações de versão do package.json. Eu atualizei minha postagem original, pois uma atualização é provavelmente mais apropriada.

A versão resumida é, Yarn não fará nada com resolvedores de cache se o lockfile não mudar, então precisamos pular a verificação do lockfile e perguntar ao cache se há uma versão mais recente. Isso pode ser feito usando upgrade ou install --force

Por yarn install --force documentação

"ele recupera todos os pacotes, mesmo aqueles que foram instalados anteriormente".

Isso realmente significa que ele ignorará a verificação de integridade do arquivo de bloqueio. A verificação de integridade do arquivo de bloqueio geralmente será aprovada se você não alterar o arquivo package.json e sair normalmente. Ignorá-lo solicita que o cache verifique se há dependências ausentes / incompatíveis no arquivo de bloqueio, baixe-as se estiverem ausentes e copie de volta todas as dependências mais recentes / ausentes localmente. Em seguida, ele executa scripts npm install / postInstall .

A mudança de PR agora invalidará a dependência file: no cache e copiará a nova versão localmente. Antes disso, ele nunca invalidaria a dependência file: . Para outros protocolos, se você não alterou o arquivo package.json, eles permanecerão inalterados (no cache e localmente).

Então, o que isso significa para nós? Tenho cerca de 60 dependências em um projeto (variando de Angular a Webpack), com uma dependência file: . Em um segundo install --force , onde desejo apenas atualizar a dependência local, leva cerca de ~ 5 segundos (de ~ 1,5 segundos para yarn install ). Para mim, isso é insignificante e, na verdade, estou muito impressionado com o quão pouco trabalho o fio tenta realizar durante todo o processo.

Se houver outro comando CLI para pular a verificação do arquivo de bloqueio e verificar o cache apenas para a dependência de arquivo específica, provavelmente seria ainda mais rápido, mas não encontrei nenhum.

Dito isso, eu ainda chamaria isso de band-aid. Isso poderia ser substituído por uma solução melhor, como link: ; Acho que ninguém realmente se preocupa em armazenar em cache as dependências locais. No mínimo, a sobrecarga adicional de usar install --force ou upgrade é negligente e você não precisa mais yarn cache clean; mv node_modules /tmp/ .

Ótima resposta. 👏 Obrigado por anotar isso.

O yarn sobrescreve os arquivos de projeto com links simbólicos locais com os arquivos do cache do yarn? (porque parece que é isso que está acontecendo)

A mudança de PR agora invalidará o arquivo: dependência no cache e copiará a nova versão localmente.

Isso significa que sempre que eu chamar $ yarn dentro de um pacote que tem "foo": "file:../" como uma dependência, uma nova cópia de "file:../" será criada?

Por exemplo, eu tenho um pacote com vários exemplos que também são pacotes:

foo/
foo/examples/
foo/examples/example-1/
foo/examples/example-2/
foo/examples/example-3/
...
foo/examples/example-10/

E parece que agora tenho foo 10 vezes no cache de fios. Eu também testo meus exemplos em cada mudança de versão de foo (e tenho vários módulos configurados dessa forma, não apenas foo ), então parece que meu cache de fios cresce _realmente_ rápido atualmente.

Este é o comportamento correto?

Acho que é uma alternativa melhor do que ter uma versão obsoleta em seu cache.
Com o yarn 0.26 você pode usar link: para criar links simbólicos em vez de copiar arquivos.
Também estamos trabalhando em espaços de trabalho que irão automatizar a criação de symlink, https://github.com/yarnpkg/yarn/issues/3294

Sim, estou ansioso por espaços de trabalho 👍

link: ainda não funciona com npm, certo? (Porque https://github.com/npm/npm/pull/15900 ainda está aberto.)

A partir da nota de patch npm 5 , os arquivos agora são automaticamente vinculados à sintaxe file: :

npm install ./packages/subdir irá agora criar um link simbólico em vez de uma instalação normal. arquivo: //path/to/tarball.tgz não mudará - apenas os diretórios têm links simbólicos. (# 15900)

Então, sim, não há link com npm.

npm install ./packages/subdir irá agora criar um link simbólico em vez de uma instalação normal

Um pouco infeliz. Os arquivos deps nunca se comportaram da mesma forma devido a copiar tudo (incluindo node_modules ) e não respeitar o campo .npmignore ou files . Agora é pior com o link simbólico.

Acho que o arquivo: e o link: poderiam ser melhorados ainda mais, existem diferentes estratégias que têm seus próprios PROs e CONs e o Yarn deve permitir que as pessoas escolham um.
Por exemplo knit RFC pode ser implementado como uma das estratégias https://github.com/yarnpkg/rfcs/blob/master/accepted/0000-yarn-knit.md

@bestander

Acho que é uma alternativa melhor do que ter uma versão obsoleta em seu cache.

Ou então você acreditaria até ficar sem espaço em disco e descobrir que o cache do Yarn está usando dezenas de gigabytes para milhões de arquivos totalmente inúteis .
IMO que torna a coisa toda mais seriamente quebrada do que antes, porque você descobre apenas depois de ter quebrado temporariamente seu sistema de desenvolvimento.

Oi pessoal, alguma atualização sobre o assunto? É realmente um grande problema para nós, especialmente quando estamos trabalhando em vários produtos ao mesmo tempo que dependem das mesmas multi-dependências vinculadas. Gigabytes de cache em um dia de desenvolvimento, etc. Você poderia pelo menos torná-lo opcional e desabilitar o cache para tais pacotes?

@nikdojo Use o protocolo yarn link: para dependências em vez de file: , ele usa links simbólicos. Foi introduzido em 0.26 .

Como alternativa, comece a usar espaços de trabalho se você tiver muitas dependências entre projetos.

@mtraynham Thx pela dica, tentei encontrar qualquer informação sobre o protocolo link: nos documentos oficiais, mas parece que não está lá. Experimentando espaços de trabalho agora.

@bestander btw como você sabe,

Isso nunca foi resolvido foi? Você tem que usar linklocal (pacotes NPM) para vincular pacotes locais (que deve ser a maneira padrão como o yarn opera ao consumir pacotes do sistema de arquivos local - usando junções ou links simbólicos no Windows em vez de cache). Um novo yarn install então sobrescreve tudo com o material antigo do cache e você tem que começar a vincular novamente.

Podemos ser menos astronautas da arquitetura e simplesmente não armazenar pacotes locais em cache? Este problema já tem 1,5 anos e estou cansado de executar yarn add ../<another-local-package> toda vez que mudo algo em another-local-package .

Hi @fungilation
Abri outro problema relacionado: # 6037

não funciona
Eu coloquei no arquivo App.js
console.log ('aqui estamos') e não foi gerado.
em seguida, remova todos os arquivos e ainda fará a saída do cache.
Como evitar isso?

Yarn realmente me falhou nesse assunto. Tem sido ótimo para todo o resto, exceto para isso.

Tenho tentado instalar uma nova versão de um pacote local para fins de teste e continuo terminando com o pacote antigo, não importa o que eu faça.

Eu tentei:

1. Limpando o cache de fios ( yarn cache clean package-name )
2. yarn add 'ing com --force
3. Removendo node_modules/package-name e yarn add ing novamente
4. Atualizar o número da versão e o nome do arquivo do pacote local (o yarn ainda instala o conteúdo da versão antiga , embora relata a instalação da mais recente)
5. Combinações de todos os itens acima

Isso é ridículo, e passei quase 4 horas do meu dia nisso.

Precisamos desenvolver e reinstalar pacotes locais . Estou contando com o yarn para instalar um arquivo na pasta .bin, então yarn link está fora de questão.

@Yarn Developers: Você consegue instalar um pacote local, fazer alterações nesse pacote local e, em seguida, fazer com que as alterações sejam refletidas instalando-o novamente?

@gregjacobs eu tive sucesso com yarn install --force

@jonathantorley Acabei de tentar novamente com --force e ainda não funciona com o yarn 1.12.3

Para outras pessoas que enfrentam esse problema: uma solução alternativa que usei para realmente fazer isso funcionar era aumentar o número da versão do pacote dependente. Um pouco chato, e você tem que se lembrar de fazer isso em cada alteração (a menos que você possa fazer um script).

yarn definitivamente não deve exigir esta solução alternativa ao instalar pacotes locais

Eu adicionei yarn upgrade MY_PACKAGE_NAME no script preinstall , e ele atualiza para a versão mais recente do NPM também. (Ainda assim, preciso alterar a versão do NPM manualmente).

Parece que yarn add file:PATH agora sempre atualiza o novo conteúdo agora no yarn 1.13.0.
yarn install ainda não.

@leavesster Ainda não é para mim.

Eu tenho que renomear o tgz para que ele seja atualizado

Tente usar o comando link : https://yarnpkg.com/lang/en/docs/cli/link/

yarn add file:PATH não atualizou o novo conteúdo para mim. Além disso, os arquivos em package.json e .npmignore não são respeitados.

Funciona quando você muda a versão do seu pacote.

Se você quiser que yarn add file:PATH respeite os arquivos em package.json e .npmignore, você deve executar yarn pack em sua dependência de pacote local e, em seguida, onde deseja instalá-lo, execute yarn add file:path-to-local-pacckage.tgz

Tente usar o comando link : https://yarnpkg.com/lang/en/docs/cli/link/

yarn link não pretende responder ao mesmo problema. Não é bom se alguém quer o pacote npm como se fosse publicado respeitando os arquivos em package.json e .npmignore

@leavesster Ainda não é para mim.

Eu tenho que renomear o tgz para que ele seja atualizado

Não tenho nenhum tgz em meu pacote, que utilizo yarn add file: PACKAGE_PAH para adicioná-lo ao projeto atual. Só tenho o código js no meu pacote. Talvez tgz ainda esteja errado?

não está funcionando para mim também

@bestander, por que esse problema foi encerrado? O Yarn ainda armazena em cache arquivos locais e pacotes tgz. Os espaços de trabalho não são uma solução em alguns casos, por exemplo, se um pacote tem deps com versões específicas e outro pacote devDeps os mesmos pacotes do primeiro, mas com outras versões, e se você vincular um pacote a outro, seu projeto foi quebrado .

Eu tenho o mesmo problema que @gregjacobs. yarn cache clean package não ajudou. Mas eu descobri que se você instalar yarn add path/to/package.tgz e então substituir o arquivo por outro, você pode instalar uma nova versão simplesmente mudando o caminho como yarn add path/to/../to/package.tgz , então o caminho absoluto é o mesmo, mas para o yarn é diferente .

Não entendo onde mais pacotes de armazenamento de yarn em cache por caminho de resolução, mesmo yarn cache list --pattern package está vazio.

Acho que o problema está em algum lugar aqui https://github.com/yarnpkg/yarn/blob/eb2b565bb9b948e87b11119482ebc184a9d66141/src/resolvers/exotics/tarball-resolver.js#L58 -L63

O que está acontecendo:

• Do url path/to/package.tgz gera hash (é por isso que path/to/package.tgz e path/to/../to/package.tgz resultam em hashes diferentes)
• Com esse hash, cria-se um diretório temporário para o pacote (como este /Users/kich/Library/Caches/Yarn/v4/.tmp/c019816ee7d10ed5e1fef4072e8cc617 )
• Para a primeira execução isValidModuleDest return false e tudo dá certo
• Pacotes Tarball extraídos neste diretório
• Arquivos desse diretório instalados no projeto
• Você modifica as fontes de desenvolvimento do projeto e constrói / empacota o novo pacote de tarball com o mesmo nome e localização do anterior
• E você tenta instalar um novo tarball, mas o hash gerado é o mesmo de antes e o diretório temporário não foi limpo após a primeira execução
• Portanto, neste momento isValidModuleDest return true
• E yarn instale a versão antiga do seu pacote
• Você executa yarn cache clean package , mas o diretório temporário permanece intocado

@bestander podemos simplesmente remover o diretório temporário aqui https://github.com/yarnpkg/yarn/blob/master/src/config.js#L431 ?

Enfrentando o mesmo problema, o cache na pasta temporária leva 10 GB depois que eu trabalho no meu pacote local por apenas um dia!

Podemos reabrir este problema? Estamos enfrentando o mesmo problema. Dois projetos que fazem referência a outro pacote por meio de arquivo:. Depois de algumas compilações em nosso servidor CI / CD, a pasta de cache está começando a ocupar muito espaço.

Acho que o protocolo de link é a melhor solução para isso, file: // não funciona, pois ainda requer a limpeza manual de caches e instalação forçada

https://github.com/yarnpkg/yarn/issues/2165#issuecomment -345825904

apenas faça sua dependência algo assim

"<package>": "link:./libs/<package>"

@alxtz o protocolo de links funciona com pacotes em tgz?

Acho que o protocolo de link é a melhor solução para isso, file: // não funciona, pois ainda requer a limpeza manual de caches e instalação forçada

# 2165 (comentário)

apenas faça sua dependência algo assim

"<package>": "link:./libs/<package>"

Obrigado por isso, isso replica o comportamento do NPM, que vinculará simbolicamente file:.. referências em node_modules . Ele não parece estar documentado, pelo menos não aqui onde eu esperava encontrá-lo: https://yarnpkg.com/lang/en/docs/package-json/

Infelizmente, link não pode ser usado em todos os casos.

Por exemplo, eu preciso de uma dependência compartilhada / par do meu pacote SDK, que quando eu fizer alterações, eu vincularia para trabalho de desenvolvimento local.
Com link , yarn não percebe que a dependência é uma dependência compartilhada / par e usa o pacote local onde está o link simbólico, o que é incorreto.

Tenho usado yarn pack ao lado de yarn add file:<path_to_packed_tgz> para contornar isso.
Embora eu possa continuar a renomear o pacote sempre que empacotar e colá-lo em meu repositório, para não gerar o mesmo hash, conforme @wKich fantástico achado, é muito chato.

Eu fiz um fork do repo e coloquei uma cláusula extra na instrução if para impedir que o yarn carregue um pacote local .tgz de seu cache se for especificado usando yarn add file:<path> .

const dest = this.config.getTemp(crypto.hash(url));
// If specified using file: never load from cache
if (!url.match(/file:/) && (await this.config.isValidModuleDest(dest))) {
  // load from local cache
} else {
  // continue as if it's a new package
}

Posso fazer uma RP se as pessoas quiserem, embora nunca tenha feito isso antes e é uma solução bastante hacky.
Alguém poderia confirmar se esta abordagem continuaria a adicionar os pacotes locais ao cache do yarn ou não?

@ojboj por enquanto, yalc pode ajudar até que isso seja corrigido. Tem funcionado muito bem para mim testar os pacotes localmente antes de publicá-los.

@souporserious Isso é exatamente o que eu precisava / queria, muito obrigado!

Insano, isso ainda é um problema depois de tantos anos.

Está corrigido em [email protected]?

@wKich eu acredito que sim! Não testei pessoalmente, mas parece que eles resolvem o desenvolvimento local por meio do novo protocolo do portal .

Ainda recebo o erro "unpack in same destination" usando o protocolo link: , e ele faz referência ao meu diretório de cache, então me parece que o yarn ainda está armazenando em cache link: dependências. Estou me referindo a 2 cópias do mesmo pacote local, copiadas para a pasta .deps/ de cada aplicativo que o utiliza - front-end e renderer no erro abaixo. (Não é possível vincular ao original por motivos não relacionados)

warning Pattern ["@horizon/common<strong i="11">@link</strong>:packages/front-end/.deps/@horizon/common"] is trying to unpack in the same destination "/home/garyo/.cache/yarn/v6/[email protected]/node_modules/@horizon/common" as pattern ["@horizon/common<strong i="12">@link</strong>:packages/renderer/.deps/@horizon/common"]. This could result in non-deterministic behavior, skipping.