Yarn: Não avise sobre dependências opcionais incompatíveis

Parece um uso apropriado de advertir para mim.

Não seria melhor consertar o que está dando o aviso em vez de apenas escondê-lo?

@wtgtybhertgeghgtwtg

O que você quer dizer com "consertar"? Conforme explicado em https://github.com/npm/npm/issues/11632 , tudo está funcionando conforme o esperado. Alguns pacotes dependem de fsevents especificamente no macOS (porque oferece uma experiência superior), mas retornam a outro comportamento no Windows / Linux. O fato de que fsevents é incompatível com o Windows não deve ser explicado aos usuários: é apenas um detalhe de implementação específico da plataforma de uma dependência. Não há nada acionável para os usuários (e nada para se alarmar).

Eu diria que exigir uma dependência e adicionar binários para um sistema operacional específico não deve ser assim.
Tenho certeza de que existem outros pacotes que fazem esse problema aparecer, mas fsevents é o mais predominante, obtendo problemas em babel , webpack , seu create-react-app , e com certeza muito em breve sane e jest . Acho que seria mais produtivo encontrar uma solução de monitoramento de arquivos melhor, em vez de alterar o comportamento de um gerenciador de pacotes devido às deficiências de um pacote.

Se você tiver uma sugestão alternativa sobre quais pacotes usando fsevents (ou fsevents si) podem fazer, eu gostaria de ouvir isso! Eu não acho que haja nada de "errado" em ter um pacote específico do sistema operacional. Resolve um problema real e alguns problemas são específicos da plataforma.

Parece que as opiniões estão divididas.
Suponho que advertir sobre algo não acionável pode ser irritante.
Por outro lado, avisos semelhantes, por exemplo, "este módulo não funciona em Node.js <4", são bastante úteis.
Existe alguma configuração que as pessoas possam ativar para desativar os avisos?

@gaearon dado que este é um

@jhabdas

que tal um PR para adicionar um sinalizador CLI para suprimir por nível de registro

Eu adoraria enviar um PR, mas, como @bestander , também trabalho em tempo integral na manutenção de outros projetos de código aberto e, infelizmente, não tenho tempo para trabalhar neste recurso específico. Levantei uma questão para discutir se é desejável ou não.

Seria muito incorreto esconder um problema de downstream nos pacotes que você está se referindo, seja um computador superior ou apenas um RPi de $ 35 que pode fazer a mesma coisa.

Eu não entendo esse comentário. Não estou sugerindo “passar por cima de um problema de downstream”. fsevents não está fazendo nada de errado. Ele quer expressar que só é útil no macOS, mas não existe em outros sistemas. Outros pacotes, como webpack , desejam expressar que gostariam de usar fsevents no macOS, mas desejam ignorá-lo em outros sistemas. E é exatamente isso que yarn e npm estão fazendo.

Tudo já funciona como planejado, exceto que tanto npm quanto yarn também exibem uma mensagem que parece assustadora, mas não indica realmente um problema . Mas não há motivo para o usuário se preocupar, pois tudo funciona como planejado. Então, meu ponto é que seria bom parar de assustar os usuários quando nada está errado.

Desculpe se não estou sendo muito claro. Posso ver agora que isso é mais controverso do que eu esperava. Não vamos fazer isso então. Eu não vou morrer nesta colina. 😛

Por outro lado, avisos semelhantes, por exemplo, "este módulo não funciona em Node.js <4", são bastante úteis.

... mas isso é acionável - você pode atualizar sua versão do Node.js.

... mas isso é acionável - você pode atualizar sua versão do Node.js.

A limitação do sistema operacional também pode ser acionada.
Suponho que a questão seja se vale a pena exibir o mesmo aviso toda vez que você instalar uma ferramenta IO que não seja em um Mac, acho que devemos dar aos usuários do Windows a chance de não mostrá-los quando as dependências são opcionais.

Vou reabrir, parece que vale a pena discutir mais.

Provavelmente poderíamos fazer o downgrade para um nível de log "info" (e introduzir o conceito de níveis de log como o npm fez).

@gearon Você poderia fornecer dois casos de teste complementares, por favor? Li os detalhes e ouvi a sugestão. Mas eu gostaria de levar pessoalmente o que você considera uma experiência assustadora para iniciantes, por algo que "quase nunca é acionável". Você mencionou o Webpack acima. Para mim, o próprio Webpack é assustador e não o uso por isso. Há muitas coisas boas que podem ser feitas com o fio se ele mantiver os olhos no conjunto de recursos correto durante o desenvolvimento. Essa é realmente uma sugestão que você acha que ajuda a atingir esses objetivos ou você está escalando a colina de outra pessoa?

Estou tendo uma situação semelhante à descrita por @gaearon : Estou recebendo avisos sobre dependências que usam dependências mais antigas e acho que simplesmente não atualizaram?

Quando executo yarn upgrade , obtenho isto no início:

warning gulp > vinyl-fs > glob-stream > [email protected] ...
warning gulp > vinyl-fs > glob-watcher > gaze > globule > [email protected] ...
warning gulp > vinyl-fs > glob-watcher > gaze > globule > glob > [email protected] ...

Mas quando eu olho para a lista a seguir, essas dependências estão atualizadas.

Eu concordo com @gaearon , ver um aviso é um pouco assustador, especialmente para mim, já que sou relativamente novo no uso do Node e mudei do uso do npm para o Yarn. Mas também é um pouco _ enganoso_ ver uma mensagem de aviso, pois implica que é algo que posso consertar.

Na minha opinião, acho que esses avisos devem se tornar informações amigáveis ​​ou simplesmente não devem ser exibidos.

Usar dependências não seguras deve dar um aviso, entretanto.

Por que estamos falando sobre _scary_. Isso é desenvolvimento de software, não jardim de infância.

@wtgtybhertgeghgtwtg O que me a) não é _minha_ culpa, o erro não é meu eb) onde ir para ver se o problema foi resolvido. Esse tipo de informação pode evitar que os usuários descam pela toca do coelho e tentem descobrir o que há de errado com eles.

Boa ideia para melhorar a mensagem primeiro, envie um PR

Em 7 de julho de 2017 às 14:08, Daniel Blake [email protected] escreveu:

@wtgtybhertgeghgtwtg https://github.com/wtgtybhertgeghgtwtg O que joga
me é que o aviso me pede para atualizar algo que não consigo atualizar.
Mesmo que, neste caso, não seja eu quem está usando a dependência insegura (eu
acho que Glob é), eu entendo seu ponto e concordo que deve ser um aviso; mas eu
acho que pode ser redigido para ser mais informativo. Algo tão simples como
"[dependency_A] está usando um [dependency_B] desatualizado" - Eu saberei imediatamente
o morcego que a) não é minha culpa, o erro não é meu, e
b) onde ir para ver se o problema foi resolvido. Esse tipo de
informações podem evitar que os usuários entrem na toca do coelho de tentar descobrir
o que há de errado com eles.

-
Você está recebendo isso porque modificou o estado abrir / fechar.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/yarnpkg/yarn/issues/3738#issuecomment-313793331 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/ACBdWI1Ks6bSYH_BStzm_b3-ne3bUMT3ks5sLp5PgaJpZM4OGrsi
.

O que me surpreende é que o aviso me pede para atualizar algo que não consigo atualizar.

Se estiver usando uma dependência, você certamente a possui e tudo que ela puxa, e tem a capacidade de bifurcar e melhorar tudo o que vier com ela. Se te incomoda talvez não valha a pena usar.

Enquanto eu argumentaria que

warning gulp > vinyl-fs > glob-stream > [email protected] ...
warning gulp > vinyl-fs > glob-watcher > gaze > globule > [email protected] ...
warning gulp > vinyl-fs > glob-watcher > gaze > globule > glob > [email protected] ...

diz o que você precisa saber, concordo que poderia ser redigido de uma forma que o resumisse um pouco melhor.

Podemos manter esse problema focado em um caso específico, por favor? Não quero que isso se transforme em uma confusão sobre todos os avisos possíveis.

Eu relatei um aviso específico onde "consertar" o problema é impossível em princípio, nem mesmo nas dependências transitivas. Tudo funciona como planejado.

Outros casos descritos neste problema mostram problemas legítimos que precisam ser relatados e corrigidos por dependências transitivas. Não acho que seja semelhante ao problema que descrevi. Se você tem uma opinião forte sobre eles, envie um novo problema.

Não quero que isso se transforme em uma confusão sobre todos os avisos possíveis.

Se estiver relacionado, a conversa provavelmente deve ir bem aqui. Observe o número de questões em aberto e que esta é uma solicitação de melhoria e não um bug.

Parece bom. Vou cancelar a inscrição, mas espero que essa discussão continue focada no futuro. Obrigado por participar!

Mantenedores, fechem isto. Não há ninguém para seguir adiante.

Você poderia fornecer dois casos de teste complementares, por favor?

Há muitas coisas boas que podem ser feitas com o fio se ele mantiver os olhos no conjunto de recursos correto durante o desenvolvimento.

Observe o número de questões em aberto e que esta é uma solicitação de melhoria e não um bug.

Mantenedores, fechem isto.

@jhabdas , agradeço seu esforço em fazer com que eu contribua mais com meu tempo para essa questão, e ressaltando que a equipe do Yarn tem o suficiente para fazer, mas não há necessidade de repetir isso. Este não é um comportamento muito amigável.

Peço desculpas, mas como já disse antes, não posso me dedicar a esse assunto. Confio nos mantenedores do Yarn para fazer as escolhas certas na priorização. Se eles acharem que o problema é de prioridade muito baixa, eles o ignorarão ou fecharão com razão.

Por favor, perdoe se eu entendi mal e você está envolvido na manutenção deste repositório. Neste caso, sinta-se à vontade para encerrar este problema.

Mas eu gostaria de levar pessoalmente o que você considera uma experiência assustadora para iniciantes, por algo que "quase nunca é acionável".

Instalar create-react-app e, em seguida, executar create-react-app myapp produzirá um aviso como parte da instalação:

warning [email protected]: The platform "win32" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.

O aviso npm é ainda mais assustador:

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/react-scripts/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@^1.0.0 (node_modules/react-scripts/node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

Felizmente, o npm nos permite especificar o nível de registro, o que o Yarn não faz. Infelizmente, temos que ignorar todos os avisos do npm por causa disso.

Por que este aviso é um problema?

Para um usuário experiente como você, isso não é um problema. Mas o aplicativo Create React é o ponto de entrada no ecossistema React e npm para muitas pessoas. Para algumas pessoas, é um ponto de entrada para o desenvolvimento web.

Eles não sabem o que é fsevents . A mensagem diz que Create React App é incompatível com o Windows. Esta é a lição deles. É ótimo se tudo funcionar mais tarde, mas se algo quebrar, eles nem sempre relatam um problema porque acham que não deve funcionar graças a esses avisos. Estou tentando combater essa impressão com esta proposta.

Por que estamos falando de assustador. Isso é desenvolvimento de software, não jardim de infância.

A suposição de que as pessoas só ficam com medo no jardim de infância é desconcertante para mim. Há muitas coisas de que as pessoas têm medo ao longo da vida. Isso inclui problemas mentais como ansiedade e outros medos (por exemplo, medo de não ser bom o suficiente no trabalho).

Pode parecer não relacionado às ferramentas JavaScript, mas realmente não está. Existem dois problemas separados aqui:

1. Avisos pouco claros e não acionáveis ​​deixam as pessoas ansiosas. Eles fazem com que confiem menos em suas ferramentas e os deixam confusos se fizeram algo errado, mesmo se não o fizeram. Isso está contribuindo para o esgotamento cognitivo tão bem descrito por Kathy Sierra .

2. O ruído de aviso não acionável faz com que as pessoas desenvolvam pontos cegos para os avisos. As pessoas aprendem a ignorá-los. Todo aviso não acionável contribui para esse custo. Já vimos acontecer muitas vezes com ferramentas diferentes, não apenas com o Yarn. É o cenário “o menino que gritou lobo”. Como resultado, no futuro as pessoas deixarão de diagnosticar problemas e gastar seu tempo e os dos mantenedores porque perderam um aviso importante no mar de avisos sem importância.

Espero que isso tenha esclarecido por que acho que vale a pena abordar. No entanto, não participarei mais dessa discussão porque você parece estar muito entusiasmado com a ideia de derrubar essa proposta e não estou disposto a investir mais energia pessoal para discuti-la com você.

Essa é a profundidade de informações que eu esperava obter do @gaearon. Obrigado por nos explicar, pois parece que sua empatia pelo aluno é brilhante e isso é louvável.

Acho importante ensinarmos os alunos a pescar por si próprios. E às vezes isso significa não protegê-los de seus medos, mas sim encorajá-los a enfrentar o medo de frente.

No caso de um aviso fsevents , mesmo como uma dependência opcional, os alunos devem ser encorajados a observar o aviso e procurar entendê-lo. Caso contrário, eles não crescerão.

Uma pesquisa rápida de Stack Overflow, por exemplo, apresenta a seguinte solução para lidar com a mensagem de aviso descrita: https://stackoverflow.com/a/42938398/712334.

Se a sobrecarga cognitiva se tornar uma preocupação, eu encorajaria um indivíduo a buscar uma ferramenta diferente para criar seus aplicativos de página única ou iniciar sua jornada de conhecimento em algum lugar mais adequado para obter os fundamentos da web.

@ glen-84 você gostaria de compartilhar sua opinião ou apenas passar o dedo por aí?

Certo.

• Mostrar um aviso sobre algo que não é acionável e não causa nenhum problema resulta em:
  
  
  
  • Tempo perdido pelos desenvolvedores, primeiro tendo que descobrir por que está acontecendo e, em seguida, ter que ignorá-lo todas as vezes (e ignorar avisos é uma coisa ruim)
  
  
  • Tempo perdido pelos desenvolvedores do Yarn / npm, tendo que explicar por que isso acontece
  
  
  • Erros de ferramentas downstream
  
  
  • etc.
  
  
• Se você combinar os votos da questão do npm, quase 150 usuários concordam.
• Os desenvolvedores do npm já aceitaram a mudança, em teoria.

Eu votei contra dois de seus comentários, porque IMO eles não agregam valor a esta discussão.

Concordo que os avisos que não são acionáveis ​​não são úteis e também podem ser desnecessariamente assustadores / barulhentos /. Vamos com @dmbdesignpdx 's sugestão como @bestander sugeriu?

Boas-vindas do PR.

Tempo perdido pelos desenvolvedores, primeiro tendo que descobrir por que está acontecendo e, em seguida, ter que ignorá-lo todas as vezes (e ignorar avisos é uma coisa ruim)

Você não o ignora. Você aprende por que está acontecendo e age. Às vezes, isso levará a outro conjunto de ferramentas ou a um problema no repo que trata da causa raiz, conforme sugerido por @Vanuan no problema de NPM relacionado.

Tempo perdido pelos desenvolvedores do Yarn / npm, tendo que explicar por que isso acontece

Não é responsabilidade do Yarn resolver problemas de repositórios individuais ou gerenciadores de pacotes. E a NPM não é o único empacotador que existe. E pessoalmente, prefiro ver Yarn crescer para substituir o Composer e preencher o vazio que Bower acabou de deixar a comunidade, em vez de se distrair com pistas falsas.

Se você combinar os votos da questão do npm, quase 150 usuários concordam.

Isso é argumentum ad populum. O projeto por comitê nunca funciona bem para ninguém.

Removido o rótulo cat-discusson desde que tivemos nossa discussão e agora temos uma coisa a ser tomada: torne o aviso mais útil, declarando qual pacote depende daquele outro pacote obsoleto.

@jhabdas Acho que concordamos nas partes "aprender" e "agir". A parte em que não concordamos muito é como o fazemos e se é o dever de yarn s ou não. Por enquanto, acho que quanto mais o fio é útil para seus usuários, melhor ele é. Dito isso, eu não priorizaria isso para tirar recursos de correções e atualizações mais críticas, portanto, encaminhamos para a comunidade um PR.

Se alguém quiser discutir mais sobre esse assunto, vamos passar para o Discord. Você pode me enviar um ping diretamente para chamar minha atenção. 💓

Você aprende por que está acontecendo e age

Que ação devemos tomar?

Não é responsabilidade do Yarn resolver problemas de repositórios individuais ou gerenciadores de pacotes.

São os desenvolvedores Yarn e npm que verão problemas relatados repetidamente sobre esse assunto e terão que gastar tempo com triagens desnecessárias de problemas em vez de trabalhar em novos recursos e correções de bugs.

Isso é argumentum ad populum. O projeto por comitê nunca funciona bem para ninguém.

É tudo o que temos agora, e se você discordar dessas mudanças, seu voto negativo sobre o problema ajudaria os mantenedores na tomada de decisão.

Okay @ glen-84 gentilmente me lembrou que o problema original não era sobre subdependências e mensagens informativas, mas simplesmente não alertava sobre um pacote que não pode ser instalado em uma plataforma específica.

Portanto, agora a ação para este tíquete específico é simplesmente reduzi-lo de um aviso para informação ou depuração, pois não agrega valor. Objeções? Movida a outra parte para # 3869.

@gaearon Uma alteração no código de uma linha sem teste de unidade foi feita para resolver esse problema. Por favor, lembre-se disso.

@jhabdas já respondi no PR. Esta é minha filosofia https://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests/153565#153565, mas se você acha que a compatibilidade do pacote ou aquela parte em particular precisa de alguns testes, por favor abra uma solicitação de pull e agradeço antecipadamente :)

Eu confio no seu bom senso, mas eu confio TÃO tanto quanto eu posso jogar um galho. Mas está tudo bem. Eu queria enviar minha mensagem para o benefício de outros, para ver como uma mudança de código de uma linha poderia ter evitado todo esse tópico. Às vezes, as ações falam mais alto do que palavras. Felicidades.

@jhabdas por mais que aprecie suas contribuições, gostaria de lembrar nosso código de conduta , especificamente os seguintes itens:

• Usando uma linguagem acolhedora e inclusiva
• Ser respeitoso com os diferentes pontos de vista e experiências
• Mostrando empatia para com outros membros da comunidade

Minhas mais sinceras desculpas. Vou revisar o código de conduta e tentar fazer o melhor para ser um bom cidadão da comunidade. Obrigado por me apontar na direção certa, @BYK.

Obrigado por corrigir isso. 😍 🙇

Foi a questão mais votada no NPM por uma ampla margem e causou problemas reais, mas depois de 1,5 anos sem abordá-la, seu bot simplesmente a fechou automaticamente por ser muito antiga!

Esse tipo de gerenciamento de projeto é um dos motivos pelos quais mudei para o Yarn.

Vendo como a correção foi fácil, é angustiante quanto tempo e esforço foram desperdiçados com isso. 😢

Obrigado!

Oi, obrigado por todos os esforços sobre isso. É muito mais melhor que seja agora no meu stdout em vez de stderror;). Mesmo assim, mesmo o nível de informação trará aqui toneladas de pessoas. E a única saída que eles terão após uma hora de leitura de problemas relacionados é que eles precisam conviver com isso no momento (quem não usa o babel) e que fazer a otimização específica da plataforma através de dependências opcionais é possível, mas com um custo de gerenciadores de pacotes avisos para o usuário. Estou do lado de ter essa saída apenas no nível de depuração.

@kubino esse é um ótimo feedback, obrigado! Estamos cientes de que movê-lo para info não resolveria de uma vez por todas. Para isso @jhabdas realmente gastou algum tempo para torná-lo ainda melhor e genérico e enviou uma RFC . Você teria interesse em fornecer feedback e nos informar se esse RFC aborda suas preocupações?

@BYK obrigado por ainda estar interessado nisso. Estou longe de ser um especialista e talvez tenha me enganado. Você está me apontando para o RFC onde o título é "tornar os avisos de subpacotes obsoletos mais informativos". Acho que entregar avisos DESCONTINUADO para os usuários está correto por padrão (embora seja provavelmente bom ter uma maneira de suprimir avisos de pacotes específicos).
Minha preocupação era sobre dependências OPCIONAIS que servem apenas como otimização para alguma plataforma concreta, lá eu vejo muito pouco valor em poluir de outra forma tão adorável saída limpa de fios. Mas, como disse, não sou um especialista e não tenho certeza se isso é sempre tão claro para determinar

@kubino não precisa ser um especialista. Você sabe que o mundo está cheio de especialistas autoproclamados, então é melhor alegar que não é um especialista e talvez você acabe sendo um 😀

De qualquer forma, ainda não tive tempo de ler essa RFC completamente, mas acho que ela se enquadra na seção label = "Interoperability" . Dito isso, devemos adicionar uma seção optimization para esses casos. Dito isso, vamos continuar a discussão sobre esse PR e acho que você deveria fazer essa sugestão aí e ver o que @jhabdas pensa disso.

@kubino Eu atualizei a descrição

O RFC é uma proposta para tentar ajudar a abordar uma série de casos de uso relacionados que podem surgir, introduzindo um pequeno recurso (aparentemente não relacionado) que, quando usado de forma criativa, pretende ajudar a satisfazer necessidades como aquelas que você levantou enquanto também adicionando benefícios ao grande trabalho que Yarn já realizou para a comunidade.

Fique feliz em discutir e usar seus insights para aprimorar ainda mais o RFC, pois aprendi que ser mais experiente pode ser uma desvantagem tanto ou mais como um trunfo quando se trata de codificação.

@BYK Eu sei onde você aponta;) Claro, preciso concordar com vocês dois @jhabdas , a solução genérica é a única saída para essas discussões. A categorização das mensagens é a primeira etapa que permitirá todo o resto ... vamos continuar a discussão no RFC relacionado. Obrigado!

Se for opcional "dado um SO de destino", então não deve ser nem mesmo o nível WARN. O autor está dizendo "Se o MacOS, então, use FSEvents, caso contrário, não use." Portanto, se você estiver instalando em um sistema operacional diferente do Mac, por que avisar? É mais como info / debug.

@robertjchristian Acho que há dois aspectos nisso:

1. fsevents si não funciona fora do macOS, portanto, uma tentativa de instalá-lo em tal sistema operacional deve exibir um aviso ou erro. Alguns pacotes que usam fsevents podem depender de sua API universalmente (incorretamente) sem saber que são apenas para macOS e quebrando em outros sistemas operacionais no processo.
2. Se fsevents for para alguns pacotes necessários apenas no macOS, esses pacotes devem ser capazes de marcar fsevents como não a serem instalados fora do macOS. Uma falha ao instalar fsevents no macOS resultaria em uma falha, mas em outros sistemas operacionais não haveria nem mesmo uma tentativa de instalação.

O problema principal é que tratar fsevents como uma dependência opcional é uma abordagem incorreta. O que está faltando é a capacidade de marcar fsevents como obrigatório no macOS e como completamente excluído, não apenas opcional, em outros sistemas operacionais.

Sim, isso foi explicado várias vezes no tópico original, parece que ninguém ouviu:

https://github.com/npm/npm/issues/11632#issuecomment -238217690

A solução seria adicionar suporte a dependências específicas da plataforma.

https://github.com/npm/npm/issues/11632#issuecomment -257214969

a solução 'correta' é ter algum método de dependências condicionais - uma maneira de um pacote indicar que uma ou mais de suas dependências não devem ser instaladas em algumas plataformas. Isso não é o mesmo que um pacote que se descreve como específico da plataforma - um pacote não sabe se é opcional ou não, então tudo o que pode dizer é 'se você me instalar na plataforma errada, isso é um erro'.

https://github.com/npm/npm/issues/11632#issuecomment -300804918

Aqui está o que o npm pode fazer:

1. Altere dependências opcionais e mensagens não suportadas de WARN para INFO (o que a maioria das pessoas deseja).
2. Implementar dependências específicas da plataforma (solução adequada)

Portanto, em vez de ocultar o aviso, eles deveriam corrigi-lo adequadamente, implementando dependências condicionais. Mas isso requer a alteração da especificação package.json. Eu imagino algo assim:

  "conditionalDependencies": {
    {
      "condition": { "platform": "darwin" }, // 'darwin', 'freebsd', 'linux', 'sunos' or 'win32'
      "packages": { "fsevents": "^1.0.0" }
    }
  },

Outra alternativa é para autores de eventos:

Faça com que não falhe em plataformas não OSX sem quaisquer avisos, apenas mensagem INFO sobre a plataforma não suportada

Mas isso não é muito diferente de ocultar o aviso no nível npm.

Ainda sem resposta? Esse aviso é tão irritante.

Neste ponto, estou tentado a comprar um Mac com o único propósito de não ver isso por mais quatro anos, embora eu deteste o sistema operacional 👎

Neste ponto, estou tentado a comprar um Mac com o único propósito de não ver isso por mais quatro anos, embora eu deteste o sistema operacional 👎

Se você está desenvolvendo software profissionalmente, não posso recomendar um investimento melhor.

Por que mostrar um aviso se você não exige que o usuário faça algo para corrigi-lo?

Todos que estão discutindo para manter o aviso, por favor, pensem um pouco. Se o usuário não pode fazer nada para corrigir este aviso, por que o estamos mostrando?

É como se seu parceiro lhe dissesse que está com fome, você é como cozinhar para si mesma, eles não fazem isso, você cozinha, eles não comem, mas continue incomodando, estou com fome. Cada vez que você diz oi (npm install / yarn), eles dizem que estou com fome (WARN WARN WARN) .. Parece inútil para mim.

Neste ponto, estou tentado a comprar um Mac com o único propósito de não ver este

Quer dizer que você não verá isso no Mac?
Bem, você não vai, a menos que use docker:

MacbookPro $ docker run -ti --rm node yarn add [email protected]
yarn add v1.13.0
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
info [email protected]: The platform "linux" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.

Acho que você teria melhor sorte ao bifurcar chokidar e remover fsevents de lá.
O nó recente tem grandes melhorias em relação ao suporte nativo fs.watch no OS X.

Claro, você também teria que bifurcar dezenas de pacotes dependendo do chokidar

Experimente reclamar aqui para variar:
https://github.com/paulmillr/chokidar/issues

Acho que você teria melhor sorte ao bifurcar chokidar e remover fsevents de lá.
O nó recente tem grandes melhorias em relação ao suporte nativo fs.watch no OS X.

Parece que estamos na mesma página, afinal. xD

Sim, suponho que a única opção é esperar até que chokidar elimine o suporte para o nó 10, ponto em que se tornaria inútil e outros projetos comecem a descartá-lo.

Suporte recente a node.js da @Vanuan para fs.watch ainda é uma merda. Tente realmente usá-lo em várias plataformas.

Se você quer reclamar sobre avisos de instalação, talvez reclamar para os mantenedores que "descontinuaram" os pacotes. Isso é realmente irritante pra caralho. Isso não acontecia no passado. Fsevents é muito menos um problema em comparação com isso.

Isso nunca vai ser consertado?