Yarn: Adicionar pacote sem salvar em package.json

Não, esse recurso foi omitido intencionalmente. É considerado perigoso instalar um pacote sem ser refletido no package.json. Por que você quer que tal coisa exista?

Do anúncio do Facebook

Removemos o comportamento de “dependência invisível” do npm installe dividir o comando. Executar yarn add <name> é equivalente a executar npm install --save <name> .

Costumo usar esse recurso com freqüência para testar coisas. Especialmente quando estou trabalhando com uma biblioteca que mantenho e preciso instalar uma versão local (que cria um file: dep) apenas para testar minhas alterações antes de criar uma versão.

Embora eu concorde que a implementação do npm para fazer isso por padrão foi uma escolha ruim, acho que isso pode ser útil quando usado explicitamente.

Sim, acho que permitir que seja feito com sinalizador explícito seria bom ter, atualmente para este ainda pode usar npm i =), mas apenas para se livrar da necessidade de npm.

Nós não apoiamos isso explicitamente, pois é uma mudança obrigatória para node_module que seria apagada com yarn install s subsequentes, uma vez que consideramos package.json e yarn.lock como sendo a fonte da verdade.

Temos uma dependência que não pode ser instalada facilmente no Windows (libxslt), então:

• Para Windows: os desenvolvedores descompactam em seus node_modues
• Para linux: os desenvolvedores o instalam sem salvar (se estiver no package.json, os desenvolvedores que usam o Windows não podem realizar nenhuma instalação porque a compilação falhará)

Existe uma maneira limpa de fazer isso usando fio (ou alguma maneira melhor de conseguir esse resultado)?

(Eu concordo com você que os pacotes devem ser refletidos no package.json, mas aqui não consigo encontrar nenhuma solução limpa)

@GuillaumeLeclerc Que tal yarn add -D xxx e remover a entrada do package.json você mesmo?

Ele será removido da próxima vez que outro pacote for adicionado? Não vai?

@GuillaumeLeclerc Infelizmente, sim.

@GuillaumeLeclerc Você pode querer limpar seu comentário ...

Adicione um argumento como yarn add --no-save para que eu possa instalar um módulo sem alterar meu package.json ou yarn.lock. Freqüentemente, preciso testar módulos antes de comprometer-me com eles.

Não posso usar npm install normal porque obtenho "Tamanho máximo da pilha de chamadas excedido". Portanto, o fio é a única maneira viável de instalar.

Por favor, não me faça reverter as alterações em package.json yarn.lock!

Para mim, isso está me incomodando porque estou tentando instalar um peerDep. O Yarn não tem como instalar peer deps durante install então tenho que fazer isso manualmente. Não posso yarn add <package> sem que seja adicionado ao package.json / yarn.lock. Estou preso.

@viveleroi isso parece totalmente correto. Por que você deseja instalar a dependência de par sem adicioná-la ao seu package.json ?

@hpurmann Porque está duplicando meu peerDependencies em dependencies (ou devDependencies se eu usar --dev ). Se for esse o caso, certamente não é intuitivo.

@hpurmann Eu quero publicar um componente de reação, então, reaja deve ser um peerDep. Porém, preciso instalar o react no projeto para desenvolvê-lo.

basta adicionar --no-save => é tão importante
eu preciso pular uma dependência opcional particular para um pacote específico. eu não posso fazer isso com o seu fio. pode ser com a opção --no-save, eu posso resolver isso

Como yarn link local-pkg não instala as dependências do local-pkg no aplicativo host, gostaria de instalá-las diretamente, mas não salvá-las no aplicativo package.json, pois elas serão trazidas pelo local-pkg assim que for publicado .

Eu não entendo por que os proprietários são tão opinativos sobre isso. Se você não vê um uso dele, não significa que não haja nenhum. Acredito que se as pessoas pedem, isso significa que precisam e não são necessariamente estúpidos.
Adicionar uma opção opcional --no-save resolveria o problema de algumas pessoas e não traria nenhuma desvantagem.

Estou tentando usar o Yarn para um projeto NodeJS executado no AWS Lambda. Estou um pouco surpreso porque esse recurso não é compatível. Meu caso de uso é que preciso instalar o aws-sdk em meu ambiente de desenvolvimento local, mas não quero que ele seja salvo em package.json porque o AWS Lambda já tem isso instalado em seu ambiente. Incluir aws-sdk significa que nosso pacote final ficaria inchado.

yarn link e yarn add não podem viver juntos. yarn add depende de package.json enquanto yarn link apenas liga os pacotes locais a outro local.

Suponha que você esteja desenvolvendo um pacote X que depende de Y, você é o desenvolvedor de X e Y, então você mantém X e Y localmente e vincula Y ao diretório de X. Quando você adiciona fio em X, ele apaga o link para Y.

Como você contorna isso?

~ Nesses casos, você pode simplesmente usar os comandos npm para instalar sem criar uma pegada no pacote json ou yarn.lock: ~

~ npm install [packages ...] --no-save --no-package-lock ~

como @heikomat afirmado abaixo, como o npm5 usa remoção automática após a instalação (consulte https://github.com/npm/npm/issues/16853 + https://github.com/npm/npm/pull/18921), isso é não é uma opção e pode quebrar sua pasta node_modules completamente.

ok então agora eu não posso viver sem npm então

Eu estava usando npm install em um dos meus scripts que instala dependências de submódulos locais para os node_modules principais. Isso está funcionando bem com o npm4, mas está completamente quebrado com o npm5, já que o npm5 apenas decide remover alguns pacotes durante a instalação -.- (consulte https://github.com/npm/npm/pull/18921)

Por esse motivo, eu estava tentando substituir npm install em meu script por yarn, mas não posso fazer isso, se yarn sempre toca o package.jsons dos submódulos locais durante a instalação, pelo menos não sem meu roteiro ficando silencioso e bagunçado e "limpando" depois da história

Você já tem a opção --no-lockfile , então isso faz com que a pasta node_modules não pense,
mas os desenvolvedores ainda precisam ter soluções alternativas para manter o package.json imutável.

Obrigado.

Gosto de como toda vez que alguém explica seu caso de uso peculiar para instalar um módulo, mas não o registra, os mantenedores voltam e recitam seus shiboleth. Deve tornar mais fácil sentir-se confiante em sua obstinação, se você puder expressar esse mesmo pedido de muitas pessoas diferentes como vindo daqueles que sofrem de uma falha moral. Como um meio-termo, talvez possamos nomear o switch --i-am-a-heritic-and-a-bad-programmer ?

É triste ver que a principal falha que yarn preserva de npm é seu antagonismo a qualquer pessoa fora de sua organização.

E, no meu caso, queria usá-lo como uma solução alternativa para o problema # 4297 :)
Limitar artificialmente os desenvolvedores a fazer coisas pode tornar seu produto inutilizável em certas situações.

Espere, você está brincando comigo? Isso é uma farsa. Pare de ditar como cada fluxo de trabalho do desenvolvedor deve funcionar, nunca. É exatamente por isso que NPM não combinava conosco e mudamos para Yarn. Essa ideologia de que "package.json e yarn.lock devem ser a fonte da verdade" é absurda. Os pacotes devem poder ser instalados sem modificar o código-fonte. Simples assim.

Vamos, mantenedores. É óbvio que há uma necessidade real disso por parte da comunidade. Por favor, pare de encerrar conversas inteligentes com filosofia não filtrada e mal colocada.

Agora eu descobri que yarn quebra meus testes porque tenho módulos onde preciso testar require e para fazer o teste, submeto um módulo de exemplo em ./node_modules . Yarn está excluindo os módulos de exemplo quando executo yarn install . Mais pedantismo da "fonte da verdade", presumo.

caso de uso: A ferramenta que uso requer um pacote. A equipe não usa essa ferramenta. A equipe (justificadamente) não quer que o pacote seja instalado.

Isso é seriamente frustrante. Eu uso o codelyzer como guia de estilo angular, mas o resto da minha equipe não usa e não afeta a funcionalidade do código. A única maneira de fazê-lo funcionar agora é adicioná-lo ao meu fio de bloqueio e apenas assumir que meu fio de bloqueio não mudou realmente ou usar npm, embora minha equipe use fio. Ambas são opções horríveis.

Já estamos em 2018, mas esse recurso ainda não foi adicionado, apesar dos inúmeros casos de uso válidos.

Apenas para dar outro exemplo de por que isso pode ser útil:

Temos um script que atualiza automaticamente as dependências instalando a nova versão, executando os testes e ENTÃO salvando-o em package.json / *.lock e confirmando essa alteração OU revertendo se houver um erro. É muito mais fácil apenas executar yarn novamente em vez de lembrar a versão antiga e explicitamente adding novamente.

Além disso, parece mais limpo não alterar seu único ponto de verdade ( package.json ) antes de "absolutamente" ter certeza de que você é realmente capaz de atualizar essa dependência sem quebrar um teste. Por enquanto, você acaba com um package.json (mesmo que seja temporariamente) contendo uma dependência que quebra seu código.

Existem muitos casos de uso válidos para esse problema. Os mantenedores do yarnpkg estariam dispostos a aceitar um PR se um fosse criado?

pingando @kittens se você ainda for afiliado a este projeto ...

Nesse ínterim, uso o seguinte script na seção scripts de package.json :

"scripts": {
  "install-sneaky-package": "npm install -g sneaky-package && cp -r $(npm root -g)/sneaky-package ./node_modules/sneaky-package"
}

Presumo que haja uma alternativa para o fio?

Não há alternativa, o npm5 é uma bagunça como minha vida.

E não se esqueça de copiar os links simbólicos na pasta .bin. ;)

Para mim, chmod 444 package.json e yarn add XXXX --no-lockfile pelo menos resolve o problema de desenvolvimento e teste local.
A adição termina com um erro de permissão (esperado), mas o módulo adicionado está presente em node_modules depois e posso testar com dependências de pares instaladas localmente, mas não persistentes no package.json, mas como dependência de pares.

Às vezes, exijo uma biblioteca de depuração temporariamente, como why-is-node-running . Eu sei que vou querer me livrar dele após um único uso, e uma opção --no-save me permitiria instalar e esquecer, sem correr o risco de poluir minhas dependências.

Estou usando o Lerna e realmente quero instalar _apenas_ Lerna em uma das minhas etapas de CI, para o estágio de publicação, visto que o projeto já foi construído em uma etapa anterior e os artefatos foram transportados. Esse é um cenário válido?

Isso me pouparia alguns passos, se esse recurso estivesse disponível.
Meu node_modules está em .gitignore de qualquer maneira.

Ao invés de:

git clone external-package (needed for temp testing only)
yarn install
yarn link

volte para o meu repositório original
yarn link external-package

somente:
original-repo:
yarn install external-package --no-save

Como parte de nossos pipelines de construção, precisamos instalar o nsp e executá-lo, exportando um dependency-check.xml.

Não vejo por que essa simples instalação de ferramenta precisa ser refletida na lista de pacotes, isso apenas significa que agora preciso fazer um git checkout ${BRANCH_NAME} para desfazer as modificações antes de enviar tags.

Não estou tentando modificar a fonte. Eu não quero e não é da minha conta, isso depende das equipes de desenvolvimento da minha organização. Você está tornando minha vida um pouco mais difícil para alguma filosofia abstrata. Pare com isso.

Alguma ideia, por que esse assunto foi encerrado? O switch --no-save foi adicionado em um PR?

Há momentos em que desejo alterar a versão de um módulo trazido de uma dependência. Por exemplo, @types/sinon trazido por outra dependência de dev quebrou meu tsc recentemente. Não quero @types/sinon para minhas dependências de desenvolvimento, mas quero alterar manualmente a versão com yarn add @types/[email protected] --no-save para que eu possa continuar trabalhando. Em vez disso, eu apenas volto para o npm. Super frustrante.

Eu tenho uma dependência somente de produção (appdynamics) que é em si um hack de binários específicos da plataforma. Acontece que nem precisamos disso nas máquinas de desenvolvimento. Adicionar yarn add ... --no-save nos deixaria implantar de forma limpa, sem que o script coloque em risco o package.json (especialmente porque o package.json, desagradavelmente, não pode ter comentários explicando o propósito de cada script ou dependência)

cc @kittens @hpurmann

Resolva este problema incrivelmente popular ou bloqueie-o como resolvido. Seria muito grato ter uma resposta concreta em resposta a todas as críticas levantadas acima.

E a comunidade está pronta para fornecer o recurso, diga-nos se você aceita tal solicitação de pull. Obrigado.

haha, ainda não implementado, niiiiice

Por que você quer que tal coisa exista?

Foi exatamente a mesma coisa que as pessoas disseram sobre JSX quando ele foi lançado, misturando modelos e lógica. Se for possível e tiver seus casos de uso, a pergunta correta seria por que não? Quero dizer, é um sinalizador, não é um comportamento padrão, então você está contando a história explicitamente (ou seja, eu sei o que estou fazendo).

@kittens @hpurmann
Eu tenho vários pacotes com base no react e eles têm dependências de submódulos um sobre o outro. então eu tenho o react e o react-dom como um peer-dep, mas quando preciso construir esses pacotes individualmente, eu preciso o react e o react-dom.
Eu acho que este seria um caso de uso apt para instalar pacotes localmente sem tê-los adicionado como dep.
Eu não gostaria de ter npm para um uso tão trivial em meu projeto.
Quaisquer atualizações, esperando por algo semelhante a --no-save .
Eu acho que não há mal nenhum em adicionar um recurso se a comunidade exigir, assumindo que o desenvolvedor esteja ciente de seus efeitos colaterais (perder os pacotes locais assim que você executar o yarn install).
obrigado

O truque prático é yarn add --dev pkg && yarn remove pkg . Ele faz a mesma coisa. O arquivo de bloqueio permanece como estava antes, tão intocado.

Isso foi mencionado por @Legends anteriormente, mas vale a pena enfatizar:

Uma solução alternativa para alguns casos é instalar o pacote necessário em uma pasta separada e yarn link o pacote necessário onde quer que tenha sido adicionado. Não é ideal, mas pode ajudar.

cd /third-party
yarn add foo
cd node_modules/foo
yarn link

cd /my-project
yarn link foo

@silentorb definitivamente não vale a pena, imho. O add + remove é exatamente o que é feito com o --no-save no npm. Ele não mexe com os links do sistema e não está mexendo no arquivo de bloqueio de maneira ruim - o que significa que é o mesmo depois de yarn remove .
Sem mencionar que se você quiser fazer isso programaticamente, definitivamente criar diretórios, links e etc. não é o caminho a seguir.

alguns casos

Por exemplo? Muito estranhos com certeza?

@hpurmann @kittens

Então, qual é a prática recomendada para desenvolver um pacote com dependências de mesmo nível?

Se eu tiver, por exemplo, React as a peerDependency em meu pacote, devo adicioná-lo como uma devDependency também para resolver as importações?

Olhando para https://github.com/airbnb/javascript/blob/master/packages/eslint-config-airbnb/package.json , acho que a resposta é sim

@ 18steps, verifique https://www.npmjs.com/install-peers

Existem algumas situações para usar este recurso.

Assim como no ciclo de vida do CI, adicionei um repórter de cobertura. Mas não posso trazê-los para package.json então afetar a publicação de NPM .

Salve ou não salve, acho que essa escolha deve ser feita pelos próprios desenvolvedores, não pela ferramenta.

Tudo bem, vamos tentar olhar para isso da perspectiva dos mantenedores. Eu posso definitivamente ver as desvantagens de uma solução --no-save ingênua. Não obtivemos uma explicação muito completa aqui, mas tentarei construir um homem de aço. Talvez eles possam me corrigir. Talvez possamos encontrar um meio-termo. @kittens @hpurmann

(Desculpe, acabou demorando mais do que eu esperava.)

O gerenciamento de dependências para aplicativos modernos do Node e da Web é um pouco caótico. Ainda assim, queremos um sistema que nos dê automação confiável e um certo nível de controle e previsibilidade, com recursos como desduplicação e compilações reproduzíveis.

Para entender a complexidade, precisamos saber o que está instalado e por quê, e precisamos de uma única fonte de verdade para resolver qualquer inconsistência. Correndo o risco de declarar o óbvio, node_modules si não pode cumprir nenhuma dessas funções. É muito lento para atravessar, muito grande para transmitir, muito refinado para o controle de versão e não pode codificar o aspecto 'por que'. É por isso que temos package.json e yarn.lock .

O Yarn encapsula a complexidade de node_modules nos dando acesso restrito por meio de uma interface. Se prometermos não quebrar o encapsulamento, obteremos certas garantias em troca, como desduplicação e compilações reproduzíveis. Se instalarmos coisas em node_modules sem uma alteração correspondente em package.json e yarn.lock , perderemos essas garantias.

Além disso, esse é um contrato tácito do qual muitos desenvolvedores não estão explicitamente cientes. Quando o quebram, não o fazem conscientemente. Portanto, quando as coisas dão errado, Yarn pode ser culpado injustamente. Além disso, fazer uma ferramenta difícil de atirar no próprio pé não é uma filosofia de design ruim.

No entanto , posso ver vários motivos para ceder:

• Parece haver uma necessidade definitiva aqui. Basta olhar para os muitos casos de uso listados nos comentários acima e as relações de 'polegares para cima' / 'polegares para baixo'. A aparente teimosia dos mantenedores em face de tal resposta unilateral não faz Yarn parecer muito bom.

• Existem soluções a serem encontradas que podem funcionar para todos. Por exemplo, introduza um novo arquivo yarn.local.lock . Os desenvolvedores o colocariam em seus .gitignore e ele manteria um registro de todos os pacotes instalados com o sinalizador --no-save e suas dependências.

  Para manter yarn.lock isolado disso, a desduplicação e o achatamento da árvore de dependência 'local' são restritos. O arquivo de bloqueio local pode se adaptar para corresponder a uma versão no arquivo de bloqueio principal (e desduplicar, nesse caso), mas não o contrário. Como resultado, muitas dependências locais transitivas podem não ser niveladas em node_modules .

  Com esta solução, o Yarn pode continuar a monitorar todos os pacotes, os desenvolvedores podem instalar coisas sem poluir seu repo e preservamos compilações reproduzíveis. (Também há espaço para package.local.json com uma seção devDependencies , mas não tenho certeza de que seria necessário.)

• As pessoas já estão usando soluções alternativas para conseguir o que desejam de qualquer maneira, pelo menos três delas descritas nos comentários acima. Mas eles são inconvenientes de usar, não oferecem as mesmas garantias e exigem que os desenvolvedores lutem contra o Yarn para descobri-los. É o pior dos dois mundos.

Posso ter perdido algo, mas parece uma conversa que vale a pena ter.

Tenho outro caso de uso: gostaria que um módulo estivesse disponível no REPL, mas não pretendo usá-lo em meu código. Do jeito que está, preciso ir para uma pasta diferente e instalar esse módulo lá, depois importar alguns arquivos json usando ../other-project/data/xyz.json .

Mas se eu quiser importar um módulo e essa coisa importar outros módulos usando caminhos relativos, bem, vai quebrar.

Deixar-me instalar um módulo em node_modules sem salvar tornaria tudo muito mais fácil.

Estou surpreso com a resistência dos mantenedores a essa ideia.

Meu Deus, acabei de ler os comentários anteriores e a atitude dos mantenedores é decepcionante. Eu desenvolvo muitos plug-ins específicos de framework que têm dependências em bibliotecas de framework e quero evitar adicioná-los como dependências rígidas em meus plug-ins.

Eu tenho um plugin que depende de pacotes específicos definidos em peerDependencies , agora o problema, como muitas outras pessoas já comentaram, é como diabos você instala as dependências localmente sem adicioná-las ao package.json Arquivo? Bem, você não pode.

A única solução que encontrei é instalar peerDepencies como devDependencies que não parece ideal, mas resolve o problema. Pelo menos npm em seu estado horrível é instalado sem modificar seu arquivo package.json .

@hpurmann @kittens

Você desistiu de responder à comunidade? Claramente, ignorar esse problema não está ajudando você e ele não vai embora. De que adianta chamar isso de projeto de código aberto se você nem vai responder à simples pergunta de se alguém faz o trabalho e envia um PR, você vai aceitar?

Eu provavelmente deveria ter respondido há algum tempo, logo depois que @viveleroi explicou seu caso de uso bastante válido (que muitos de vocês parecem ter). Naquela época, eu fiz sinal de positivo com a resposta, o que obviamente não é suficiente para ser notado.

Eu mudei de ideia. Normalmente, as pessoas querem muitas coisas e se os mantenedores estão aceitando todos os recursos, o software fica inchado. Não tenho esse caso de uso, mas vejo muitas pessoas querendo isso.

Não consigo decidir nada, no entanto. Não sou mantenedor deste projeto.

@Vheissu Qual é o problema com yarn add --peer <dep> ?

para mim yarn add --peerfunciona ATÉ que você adicione outro pacote, momento em que os peer deps existentes são removidos da instalação local e você deve lê-los manualmente.

Eu gostaria desse recurso porque hoje, porque estou escrevendo um exemplo de implementação da minha biblioteca usando express, mas nenhum de meu código depende diretamente do express. Não quero que nada seja instalado ou dependa do Express, mas quero instalá-lo em meu diretório atual.

Assim como @ brendan-hurley @suyanhanx , tenho dependências que desejo instalar em CI e não localmente.
Eu quero manter minhas dependências locais no mínimo, para que não tenhamos que aumentar node_modules e nos custar tempo e espaço para cada desenvolvedor trabalhando no projeto.

Pacotes que são necessários em CI, mas não localmente:

• Ferramentas específicas de CI: liberação semântica, greenkeeper-lockfile
• Ferramentas de relatório de cobertura: cobertura de código, macacões
• Ferramenta de relatório de teste para CI: jest-junit, etc.

É por isso que precisamos desse recurso:

Usando yarn link não vai ligar as dependências do pacote, então você precisa instalá-los em
o destino vinculado - ter essas dependências externas adicionadas a package.json só o torna muito inconveniente.

Tanto yarn link tem que adicionar dependências ou fornecer uma maneira de excluir o destino package.json

Tenho um caso de uso bastante esotérico, mas isso seria útil para mim. Eu entendo perfeitamente por que é importante que yarn.lock e package.json sejam a fonte da verdade, e que se eu usasse um comando --no-save , minhas alterações seriam apagadas em yarn subsequentes

Dito isso, gostaria que yarn confiasse em mim para saber o que estou fazendo e me permitisse passar a bandeira --no-save . Se eu encontrar qualquer um dos casos problemáticos, saberei exatamente o que deu errado e só posso culpar a mim mesmo. :sorriso:

Meu caso de uso?
Eu executo uma máquina win de 64 bits.
A máquina Prod é de 32 bits.

Dependência Node-sass que temos suporta apenas 32 bits, a menos que atualizemos o pacote.

Não alterar a dependência no package.json ou yarn.lock para oferecer suporte a uma máquina de desenvolvimento.
Portanto, gostaria de instalar localmente o node-sass mais recente para oferecer suporte a 64 bits, mas não afeta o package.json e o yarn.lock

Gostaria de instalar pacotes de @types/* em projetos não TypeScript sem contaminar package.json / yarn.lock para melhor autocompletar em VSCode.

Eu uso lerna com espaço de trabalho de fios.
A definição de tipo do Antd é interrompida devido à atualização de @ types / [email protected] .
Antd vai consertar isso no fim de semana.
Mas agora preciso forçar o yarn a instalar uma versão fixa de @ types / [email protected] no workspaceRoot manualmente, sem afetar o package.json atual (já que ele instalará a versão mais recente automaticamente).

Manter o comportamento padrão de salvar em package.json está certo, mas há casos reais em que o desenvolvedor deve instalar o módulo sem afetar o package.json. Especialmente quando há alguma mudança inesperada em alguns pacotes.

Atualizar o pacote implicitamente e salvá-lo implicitamente em package.json leva ao conflito.

Aqui está outro caso de uso. Eu mantenho uma biblioteca React. Antes de publicar uma nova versão, desejo executar meus testes em várias versões de react e react-dom , para verificar se minhas alterações são compatíveis com versões anteriores e posteriores ( @next ). Eu estava fazendo isso usando a configuração abaixo, mas agora quero usar os espaços de trabalho do Yarn, então preciso migrar para o Yarn.

"test:backwards": "npm i [email protected] [email protected] --no-save && npm test",
"test:forwards": "npm i react<strong i="9">@next</strong> react-dom<strong i="10">@next</strong> --no-save && npm test",
"test:latest": "npm i react<strong i="11">@latest</strong> react-dom<strong i="12">@latest</strong> --no-save && npm test",
"test:compat": "npm run test:backwards && npm run test:forwards && npm run test:latest"

Não posso permitir que este script mude meu package.json pois isso faria meu comando de publicação ( pack publish ) falhar devido a mudanças não programadas.

Quero adicionar pacotes adicionais em meu pipeline de CI para fins de teste sem tocar no arquivo package.json (pode ser uma montagem de arquivo somente leitura).
Eles não fazem parte dos componentes de desenvolvimento.
Durante o desenvolvimento e teste nas máquinas de desenvolvimento, eles não devem ser instalados e durante a construção e produção eles não devem ser instalados, eles só são necessários e aceitáveis ​​no servidor de CI durante os testes.

Isso funciona apenas com o npm, mas o yarn deve ser capaz de remover a depência com o npm.
Isso pode nos levar de volta a usar apenas npm em vez de apenas fios.

Além disso, quebra a promessa de o fio ser capaz de substituir completamente o npm, porque ele simplesmente não pode fazer o que o npm pode.

Além disso, sim, esconda absolutamente esse recurso atrás de alguma sinalização porque este não deve ser um caso de uso normal, mas um caso de uso extremo.

você está de brincadeira ? 3 anos para adicionar um switch simples?

Outro caso de uso: usamos um pacote npm ( git-hoooks ) para verificações pré-commit. Nem todos na equipe têm um node instalado, então incluí-lo no package.json quebraria os commits para algumas pessoas. Portanto, estou tentando criar scripts npm para ativar / desativar temporariamente os ganchos instalando / removendo os git-hooks. Muito desapontado ao descobrir que esta tarefa aparentemente simples e fácil é virtualmente impossível de realizar com fio.

Se a preocupação é que yarn.lock não será mais uma fonte de verdade para o conteúdo de node_modules, bem, o que há de tão ruim nisso? As funções existentes não poderiam simplesmente ignorar a existência de dependências não rastreadas? Yarn é uma ótima ferramenta e os mantenedores prestaram um grande serviço à comunidade JS, mas eles precisam reconsiderar essa decisão.

você está de brincadeira ? 3 anos para adicionar um switch simples?

@spanasik e @Ryuurock : por favor, seja educado ao discutir software de alta qualidade que é fornecido gratuitamente.

Isso não levou "3 anos" porque a mudança é muito complicada de implementar - é porque os mantenedores não estão convencidos de que será um benefício líquido para os usuários. Se você discordar disso, dê um argumento a favor do recurso.

@NickHeiner aqui estão 10 telas de argumentos. E o principal que motiva a frustração, não é que os mantenedores não estejam convencidos, mas que eles estão ignorando, não respondem a argumentos, quando as pessoas “discordam disso, façam um argumento para o recurso”. E quando as pessoas ficam frustradas, é claro que deixam comentários desagradáveis. Por favor, não culpe os usuários por tudo isso.

Eu concordo que seria melhor se os mantenedores abordassem a discussão aqui. Há claramente interesse de um amplo conjunto de pessoas ao longo de vários anos. Então, talvez minha sugestão de que @spanasik e @Ryuurock devam apenas "apresentar um argumento" não seja razoável, porque provavelmente seria ignorado como tudo aqui.

E quando as pessoas ficam frustradas, é claro que deixam comentários desagradáveis. Por favor, não culpe os usuários por tudo isso.

Discordo. Essa grosseria ainda não é um passo útil à frente, nem um comportamento aceitável entre os adultos. Ser indelicado é uma ótima maneira de justificar os mantenedores ignorando isso ainda mais: "o tópico é apenas trolls".

Formas construtivas de seguir em frente:

1. Chame a atenção do mantenedor para este tópico em outros canais (talvez eles o tenham ignorado) e peça que pelo menos reconheçam os argumentos aqui, mesmo se eles não concordarem.
2. Garfo / substitua o fio e governe o projeto de uma maneira que as pessoas fiquem mais felizes.

O truque prático é yarn add --dev pkg && yarn remove pkg . Ele faz a mesma coisa. O arquivo de bloqueio permanece como estava antes, tão intocado.

Testado - não funciona.

Meu caso de uso é o seguinte:
Alguns pacotes possuem addins opcionais carregados com 'require'. Não quero adicionar esses suplementos à seção devDependencies, portanto, faço um 'yarn add my-add-in' e o removo manualmente do arquivo package.json. No meu pipeline de CI na nuvem, uso 'npm e adiciono-os (para teste). No meu pipeline local, não quero usar o npm porque ele cria um arquivo de bloqueio extra. Minha melhor opção agora é usar o npm e, em seguida, excluir o arquivo de bloqueio (para remover a segunda versão aparente da verdade).

Depois de ler tudo, minha pergunta aos mantenedores é esta:

• Por que você é tão inconsistente?
• Por que não implementar essa filosofia em todos os recursos?
  
  
  
  • Isto é: Decida como as coisas devem ser feitas para todos nós e remova todas as outras opções de todos os recursos. Mantenha o curso! Seja verdadeiro consigo mesmo!
  
  

O fato inegável é que todo bom software tem configurações porque um bom software permitirá que o usuário escolha o que é melhor para sua situação . E sempre tocar no arquivo 'package.json' é uma boa prática - mas existem casos extremos em que 'yarn' simplesmente não está à altura da tarefa por causa dessa filosofia.

Gosto muito do fio porque é simples e rápido . É realmente lamentável que os mantenedores estejam travando uma batalha que certamente perderão - porque a comunidade é forçada a voltar ao npm confiável lento para fazer as coisas funcionarem.

Vamos baixar um pouco a temperatura. Ninguém precisa se sentir enojado por um
peça de software que eles podem usar gratuitamente.

Na quarta-feira, 15 de janeiro de 2020 às 23:17 Hajime Yamasaki Vukelic <
notificaçõ[email protected]> escreveu:

Sinto nojo que o fio me faça trabalhar de uma certa maneira. Eu gosto de
decidir as coisas por conta própria, e não gosto quando minhas ferramentas me dizem como
deve funcionar, insultar a minha inteligência sendo o menor dos problemas, e
não ser capaz de fazer as coisas sendo de longe o maior.

Para acreditar em regras perfeitas e que nunca haveria uma ocasião para
quebrá-los é ingênuo. Há uma diferença entre "melhores práticas" e
"faz ou morre". Como Oliver Wendell Holmes Sr. coloca:

O jovem conhece as regras, mas o velho conhece as exceções.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/yarnpkg/yarn/issues/1743?email_source=notifications&email_token=AAGKTAZRWD3XJQEGH5N5RL3Q6ACZNA5CNFSM4CVUKFMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJDBE4Q#issuecomment-575017586 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AAGKTAZSB4FNAIFLZIL547LQ6ACZNANCNFSM4CVUKFMA
.

Faça seu próprio gerenciador de pacotes, ninguém está obrigando você a fazer nada.

Nem um pouco zangado, apenas apontando o erro em sua lógica:

o fio me faz trabalhar de uma certa maneira.

O Yarn não está obrigando você a fazer nada, eles fizeram uma ferramenta (de graça) e funciona de uma certa maneira. Se você não gosta, use outra coisa.

@foxbunny Agradeço por esclarecer seu nojo. :)

Mesmo que você acredite que seja razoável e apenas sinta nojo neste caso, não acho que a linguagem seja uma forma educada de falar com as pessoas que criaram esta ferramenta disponível gratuitamente para você. Você pode dar feedback construtivo e ao mesmo tempo ser respeitoso.

@whitecolor, a equipe tem

PARE

Ou que tal todo mundo simplesmente usar a ferramenta que funciona da maneira que eles acham que é melhor e se acalmar.

Meu caso de uso é

Quero atualizar a subdependência do nosso aplicativo
Eu vinculo esta dependência a yarn link
Em seguida, uso um vinculado em nosso aplicativo
Eu adiciono alguma dependência em nossa biblioteca
A dependência lib adicionada não está instalada no aplicativo principal após yarn install (wtf no.1)
Então eu penso, ok, vamos apenas adicionar rapidamente sem salvar no aplicativo para que eu possa apenas verificar se as coisas funcionam antes de publicar a atualização em nossa biblioteca
Mas - não.

obrigado

Desculpe ver a comunidade ignorada pelos autores.

Como voluntário de código aberto, é preciso ter uma filosofia coerente ou a
projeto vai se degradar em uma bola de lama. Isso significa às vezes dizer
pessoas “não”. Se você discordar, fique à vontade para fazer seu próprio pacote
gerente, assim como o fio substituído NPM.

Na terça, 3 de março de 2020 às 03:53 Artur Kwiatkowski [email protected]
escrevi:

Desculpe ver a comunidade ignorada pelos autores.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/yarnpkg/yarn/issues/1743?email_source=notifications&email_token=AAGKTA4K3STUMXFRUDMPJU3RFTVTLA5CNFSM4CVUKFMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENTGKUY#issuecomment-593913171 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AAGKTA7WL4R3R47HBU6EPI3RFTVTLANCNFSM4CVUKFMA
.

Estou usando o Lerna e realmente quero instalar _apenas_ Lerna em uma das minhas etapas de CI, para o estágio de publicação, visto que o projeto já foi construído em uma etapa anterior e os artefatos foram transportados. Esse é um cenário válido?

^ meu comentário original - honestamente não sei por que precisaria disso e não sabia que esse tópico explodiria tão horrivelmente - mas é divertido ver e-mails sobre isso anos depois.

Estou inclinado a concordar com os mantenedores aqui:

1. Não estou convencido de meu próprio argumento. Eu acho que os mantenedores estavam sendo educados em não reclamar por ser um argumento estúpido.
2. Mesmo se alguém _não_ levantar um PR, isso significaria que a manutenção contínua do recurso seria um fardo adicional para os mantenedores, impedindo-os de manter o produto principal.
3. Este tipo de recurso seria mal utilizado por novatos despretensiosos e / ou consumidores relativamente não qualificados de fios, perpetuando ainda mais o ponto 2.

Em qualquer caso, provavelmente há uma maneira melhor e mais arquitetônica de reduzir a necessidade desse recurso.

Criei yarn-add-no-save para alcançar esta funcionalidade. Ele pode ser instalado localmente em seu projeto ou globalmente:

$ yarn add yarn-add-no-save --dev
# or
$ yarn global add yarn-add-no-save

Depois de instalado, você pode simplesmente executar:

$ yarn add-no-save <packages> # (yarn-add-no-save when installed globally)

Meu caso de uso é testar módulos que declaram peerDependencies para que a ferramenta tenha algumas opções para instalá-los automaticamente, para ver todas as opções executadas:

$yarn add-no-save --help

NOTA: Estou ciente de que salvar um pacote para instalar pacotes sem salvá-los é irônico e basicamente contraria o propósito, mas este é o melhor que eu consegui pensar e atende às minhas necessidades.

Isso é muito útil, especialmente o suporte peerDeps. Obrigado.

Existem vários bons argumentos para esse recurso. Não é como fazer o padrão, as pessoas estão pedindo que ele esteja atrás de uma bandeira clara de que apenas as pessoas que precisam dele irão usá-lo. Atualmente, como alguns outros, preciso fazer alguns testes durante a CI com outras versões de biblioteca que não quero salvar . Não consigo entender o que é tão difícil de entender aqui.

Eu tenho que yarn install xxx então yarn remove xxx .

Não tenho certeza se esse caso de uso já foi discutido. Deixe-me tentar explicar minha situação - eu tenho um monte de pacotes interdependentes uns dos outros em um repo. Todos eles usam as mesmas dependências externas com um pacote comum em subprojetos de serviço de raiz, cada pacote local precisa ser construído na ordem para o próximo consumir. Estou tentando usar espaços de trabalho de fios para isso. Para começar, não tenho nenhum pacote local definido em minha raiz package.json. Após um ciclo completo de construção de todos os componentes, acabo tendo um package.json raiz totalmente atualizado com essas dependências locais. Agora, quando este atualizado for construído em CI, todos os pacotes locais adicionados irão falhar devido à indisponibilidade. Precisamos remover essas entradas recém-adicionadas para que funcione no CI.

Eu tenho que yarn install xxx então yarn remove xxx .

o mesmo

Aqui está um caso de uso para querer ser capaz de fazer isso:

Estamos construindo uma ferramenta com um ecossistema modular para "dispositivos" dentro da ferramenta, e o plano é que uma instância local seja configurada com esses dispositivos e os tenha ativados dinamicamente por meio da configuração. Os dispositivos são publicados no npm (e podem ser chamados fora de nossa estrutura se alguém quiser).

O projeto vanilla NÃO depende desses pacotes, então salvar em package.json seria inapropriado. A configuração de uma instância específica pode exigir que um dos pacotes seja instalado localmente.

A falta desse recurso parece ser uma decisão limitante para nosso projeto, embora continuaremos a explorar abordagens alternativas.

Antes de ler a resposta dos "mantenedores" aqui, pensei que era a pessoa mais teimosa de todos os tempos.

Quase 4 anos ... 🤦

“Teimosia” não é o mesmo que “ter uma visão de design e não implementar tudo o que se pede”.

“Teimosia” não é o mesmo que “ter uma visão de design e não implementar tudo o que se pede”.

A visão do design descreve o caminho feliz e as escotilhas de escape, conforme solicitado aqui, aumentam a utilidade para a comunidade em geral.

Por que não apenas adicionar uma seção ao arquivo de bloqueio que mantém o controle das instalações "de forma livre" e instantâneos incrementais do status quo (em node_modules ), para torná-los reversíveis com segurança? Ou talvez coloque dependências em uma pasta separada de node_modules, e use node_modules apenas para manter os links expostos ao seu pacote, para que o Yarn possa realmente gerenciar coisas por conta própria e não se preocupar com instalações invisíveis sobrescrevendo e quebrando coisas.

O Git resolveu esse problema décadas antes de você. Apenas invente algo! Isso é o que o design é - contornar as limitações, em vez de combatê-las (ou ceder a elas).

A visão de túnel em ambas as extremidades aqui nasce da ignorância, do pensamento excessivo e da polarização desnecessária. Não há artes marciais, filosofia, revolução ou política; há apenas uma ferramenta, um monte de código e um trabalho a ser feito. Se a ferramenta não puder ajudar na realização do trabalho, não é uma ferramenta para esse cenário específico. E para uma ferramenta que pretende ser de uso geral completo na substituição, como o Yarn, há tantos cenários comuns sendo negligenciados aqui que ela está simplesmente cavando sua própria cova.

Sinto como se todos estivessem se empurrando subindo uma colina estreita quando podíamos simplesmente contorná-la.