Request: Passado, presente e futuro do pedido

Criado em 30 mar. 2019  ·  352Comentários  ·  Fonte: request/request

Antes de entrar em detalhes e raciocinar, irei direto ao ponto. A coisa mais valiosa que request pode fazer pelo ecossistema JavaScript é entrar no modo de manutenção e parar de considerar novos recursos ou versões principais.

Pedimos desculpas antecipadamente aos outros commiters em request que têm feito o possível para melhorá-lo, mas é o melhor.

2009

A primeira versão de request foi um dos primeiros módulos criados para o ecossistema Node.js. As primeiras versões foram gravadas em APIs anteriores à interface de retorno de chamada padrão, streams, node_modules e npm. Nos primeiros anos, request e Node.js evoluíram juntos, cada um aprendendo um com o outro. À medida que o Node.js melhorava e migrava as interfaces principais, o mesmo ocorria com a solicitação. À medida que a solicitação adotava mudanças na biblioteca e streams do HTTP principal, ela também informava melhorias como o evento pipe (que ativou o proxy de uma linha de request ) e uma das muitas reescritas do http principal (o um que eu tive que escrever).

npm

request foi um dos primeiros módulos adicionados ao registro npm. À medida que o npm crescia, também crescia a dependência de request . Mesmo agora, quando npm é usado muito mais para trabalho de front-end do que de back-end, request continua sendo um dos módulos mais dependentes no registro. No momento em que escrevo isto, módulos de 41K dependem de solicitação e é baixado 14 milhões de vezes por semana.

O lugar que request ocupa no ecossistema Node.js não é mais o de um inovador, mas de um titular. Se você pesquisar no Google como fazer algo com HTTP em Node.js, os exemplos provavelmente mostrarão request como o cliente e express como o servidor. Isso tem dois efeitos notavelmente ruins.

É muito mais difícil para novas bibliotecas realizar tarefas semelhantes obter adoção por causa da posição atual request detém sobre o ecossistema. Também é muito difícil alterar a solicitação de qualquer maneira significativa, pois a mudança não só pode não ser adotada pela maioria de seus dependentes, mas também a desalinhava com os milhares de postagens de blog e respostas de estouro de pilha que usam request .

JavaScript moderno

Os últimos anos foram dramáticos em JavaScript. Recursos sobre os quais as pessoas falaram por anos foram de ideias a padrões e a recursos dos quais você pode confiar com segurança na maioria dos ambientes. A velocidade com que eles foram adotados é impressionante, principalmente graças à atualização automática dos navegadores e a um cronograma de lançamento agressivo do Node.js.

Os padrões básicos de request estão desatualizados. Algumas pessoas podem argumentar contra essa avaliação, e eu sei quem elas são, então não ficarei surpreso, mas é verdade. Muitas vezes tenho sido cético quanto ao impacto que alguns desses recursos teriam apenas para me pegar adotando-os no atacado não muito tempo depois de estarem disponíveis apenas na versão mais recente do Node.js.

Há uma transição acontecendo agora no ecossistema para esses padrões. Como isso será bagunçado ainda está no ar e não vou tentar ler as folhas de chá e descobrir como será o futuro a esse respeito. A pergunta para request é “Tentamos sobreviver a essa transição?” Há um ano, achei que a resposta era óbvia e que sim, mas agora estou convencido do contrário.

Uma versão de request escrita para realmente abraçar esses novos padrões de linguagem é, efetivamente, um novo módulo. Já explorei este espaço um pouco e tenho um projeto com o qual estou bastante feliz, mas é incompatível com request de todas as maneiras imagináveis. Qual é o valor em uma versão de request que é incompatível com os padrões antigos, mas não abrange totalmente os novos? De que adianta ser parcialmente compatível quando existe um mundo inteiro de novos módulos, escritos por novos desenvolvedores, que estão repensando esses problemas com esses padrões em mente?

A melhor coisa para esses novos módulos é que request desapareça lentamente, tornando-se apenas mais uma memória daquela pilha legada. Assumir a posição que request tem agora e aproveitá-la para uma parcela maior da próxima geração de desenvolvedores seria um desserviço para esses desenvolvedores, pois os afastaria de módulos melhores que não têm o fardo de request História de

Modo de manutenção

Aqui está o plano.

  • request deixará de aceitar novos recursos.
  • request deixará de considerar as alterações importantes.
  • Os committers que ainda estão ativos tentarão mesclar as correções em tempo hábil, mas sem promessas.
  • As liberações serão totalmente automatizadas, qualquer mesclagem no master será publicada. Já construí isso para alguns outros projetos usando GitHub Actions .

    • Teremos que remover colaboradores inativos e aplicar 2fa, porque os direitos de commit se tornarão efetivamente direitos de publicação npm.

neverstale

Comentários muito úteis

Eu apoio totalmente isso, acho que uma mensagem de aviso e / ou suspensão de novos lançamentos é necessária.

Quanto à mudança no processo e nas diretrizes, torna meu trabalho muito mais fácil 👌

Todos 352 comentários

Eu apoio totalmente isso, acho que uma mensagem de aviso e / ou suspensão de novos lançamentos é necessária.

Quanto à mudança no processo e nas diretrizes, torna meu trabalho muito mais fácil 👌

Muito bem dito @mikeal. Estou identificando esse problema para obter mais visibilidade.

Coisas que podemos fazer - por favor, discuta e seja voluntário!

  • [] atualizar leia-me com o estado atual do projeto
  • [] atualizar pipeline de publicação ci @mikeal
  • [] fornecer um documento com algumas orientações sobre request alternativas https://github.com/request/request/issues/3143
  • [] adicione uma mensagem de aviso na instalação do pacote para usar outro pacote e consulte o documento
  • [] escolha uma data para interromper o suporte (eu voto 6 meses, mas 12 é provavelmente mais amigável)
  • [] feche todas as solicitações de recursos e prs de recursos
  • [] revisar e mesclar as correções de bugs relevantes
  • [] adicionar problema do github e modelos de RP explicando que os recursos não serão mesclados
  • [] descontinuar a próxima versão principal ( 3.x ) para que o projeto em manutenção ativa receba um aviso, mas os projetos mais antigos continuam como de costume

Faz muito sentido! Aos poucos, adotarei essa política também para a família request-promise . Felicidades por suas importantes contribuições para o ecossistema de nós!

descontinuar o pacote npm mais recente e descontinuá-lo automaticamente na publicação

Tenha cuidado com a suspensão de uso. Como Mikael escreveu acima, existem 41K módulos dependendo de request . Muitos desses módulos são úteis no estado atual e funcionam bem para seus usuários, mas seus mantenedores podem não ter tempo para retrabalhar esses módulos para usar algo diferente de request . Ao descontinuar request no momento da instalação, você basicamente descontinuará uma grande parte do ecossistema do módulo npm.

A meu ver, o modo de manutenção não é a mesma coisa que depreciação.

  • Modo de manutenção = corrigiremos bugs e vulnerabilidades de segurança para que você possa continuar usando este pacote.
  • Deprecação = ninguém deve mais usar este pacote. Isso normalmente acontece quando o módulo é abandonado e não recebe mais nenhum bug ou correção de segurança.

Eu te escuto. O texto completo

descontinuar o pacote npm mais recente e descontinuá-lo automaticamente na publicação via ci __ (talvez após o suporte ter sido interrompido?) __

Acho que deveríamos eventualmente descontinuar request porque não quero que novos projetos o usem.
Tenho tentado fazer a triagem dos problemas e prs até uma lista que possamos resolver, mas há bugs que não podemos corrigir sem uma alteração significativa. Portanto, eles não serão corrigidos e novos usuários terão problemas.

Por exemplo, seguir redirecionamentos perdem corpos de solicitação e cookies, e análise de url para remover caminhos relativos são ambos bugs, mas não tenho certeza se algum dia serão corrigidos.

Talvez a depreciação não seja a resposta certa, mas não sei como abordar isso.

Isso faz sentido?

Vamos apenas mudar a versão principal quando descontinuarmos. Dessa forma, a maioria das pessoas que dependem do projeto não verá esse erro até tentar fazer um upgrade para uma nova especialização, o que significa que estão desenvolvendo ativamente e realmente devem procurar uma alternativa.

Tenho orgulho de ter feito parte da história de request . Também verificarei bent , parece interessante, e _pequeno_, que é mais importante para mim atualmente.

Teremos que remover colaboradores inativos e aplicar 2fa, porque os direitos de commit se tornarão efetivamente direitos de publicação npm.

Tudo bem para me remover.

Acho que devemos descontinuar a solicitação porque não quero que novos projetos a usem.

Como um programador que é MUITO grato pelo módulo e que o usa o tempo todo, QUERO usá-lo em novos projetos.

Esta decisão deve ter sido muito difícil de tomar, mas é louvável ao extremo. Bem feito.

Estou orgulhoso de ter usado esta ferramenta incrível. Isso forçou a comunidade a melhorar. 🙏
Se precisar de ajuda para mantê-lo, não hesite em me contatar.

Embora eu respeite sua decisão, peço que você considere quanto código, produção e mundo real depende da solicitação atualmente. É muito mais do que as estatísticas do NPM podem dizer. Eu entendo perfeitamente o desejo de avançar para uma coisa nova e fazer algo de uma maneira nova e mais interessante ... afinal, esse é o ecossistema JavaScript, temos que perseguir a coisa nova. Mas, por favor, considere a quantidade de tempo e dinheiro que você gastaria para organizações profissionais de engenharia com a solicitação de descontinuação no atacado. Se você quiser deixá-lo no modo de manutenção, tudo bem, mas entenda que muitas pessoas não têm absolutamente nenhuma razão prática para mudar as bibliotecas. Forçar as pessoas a mudar por causa da ideologia vai levar à frustração.

Apesar de tudo, obrigado pelo trabalho árduo que todos colocaram nesta biblioteca.

Eu me pergunto qual biblioteca poderia ser considerada moderna e recomendada agora. Superagent está principalmente em modo de manutenção agora, os axios não estão totalmente ativos.

Apenas uma nota rápida para dizer obrigado (e todos os outros contribuidores) por todo o trabalho árduo ao longo dos anos neste módulo; foi um dos primeiros que usei quando comecei com o Node, então sempre terá um lugar especial no meu coração.

Vamos apenas mudar a versão principal quando descontinuarmos. Dessa forma, a maioria das pessoas que dependem do projeto não verá esse erro até tentar fazer um upgrade para uma nova especialização, o que significa que estão desenvolvendo ativamente e realmente devem procurar uma alternativa.

Acho que ainda é uma solução viável para a menção acima.

@kibertoad Parece que @mikeal está trabalhando em https://github.com/mikeal/bent . Tenho usado https://github.com/sindresorhus/got por muitos anos e é bem suportado e está em evolução.

Com toda essa conversa e a possibilidade de ser descontinuado, acho que deve haver igual menção de um módulo de substituição de maturidade atual, de utilidade paralela. Não podemos simplesmente anunciar o seu fim e depois nada sugerir, ou uma substituição com muito menos maturidade e confiança. A solicitação é usada em aplicativos sérios. Por que isso importa? Porque apesar de todos os seus "padrões desatualizados em sua essência", ele funciona diariamente, para milhares. Não se trata do mundo perfeito, mas do mundo real. Qual é a substituição no mundo real, de confiança, no dia em que a solicitação é colocada em modo de manutenção ou está obsoleta? Isso é um imperativo.

Você pode encontrar essa discussão aqui https://github.com/request/request/issues/3143

Você pode encontrar um plano de trabalho atual (cujo feedback direto é bem-vindo) pode ser encontrado aqui https://github.com/request/request/issues/3142#issuecomment -478303334

Obrigado pelo seu trabalho em request !

Os padrões no centro da solicitação estão desatualizados.

Os padrões mudam a cada poucos meses e anos, especialmente na comunidade JavaScript. As razões pelas quais request foi originalmente criado ainda não são válidas hoje?

request tem 10 anos de commits, estabilidade e testes. Por que começar do zero? Isso não é apenas adicionar mais "fadiga do JavaScript", resultando em mais bibliotecas fazendo a mesma coisa - solicitações HTTP?

É triste ver uma biblioteca tão importante e histórica na história do Node desaparecer porque os fluxos e os retornos de chamada não são mais sofisticados em 2019.

Não acredito que seja necessário descontinuar a biblioteca, ela já existe há cerca de 10 anos, é usada em muitos lugares e na verdade é bastante estável, e no final das contas. tudo o que ele faz é fazer solicitações HTTP, o que mais a biblioteca precisa? Suporte para a moda JS do mês? 👎

Os committers que ainda estão ativos tentarão mesclar as correções em tempo hábil, mas sem promessas .

ba-dum-chhh! 🥁

Esta é a depreciação responsável. Bem comunicado, com um plano para seguir em frente. Acho que outros mantenedores do software de fonte aberta podem olhar para isso como um padrão a ser almejado.

Isso é muito melhor do que esquecer um pacote e permitir que pessoas aleatórias (que podem injetar backdoor no código) como mantenedores assumam o controle quando você não se importar mais.

Request foi um ótimo pacote e agradecemos imensamente por suas contribuições para o ecossistema de nós iniciais. Você está certo em sua avaliação de que o estilo de retorno de chamada não é mais JavaScript idiomático, e há outros pacotes, como fetch, que refletem os padrões WHATWG.

@stcktrce Exatamente, a biblioteca não precisa de mais nada, ela funciona exatamente como está. Mas houve grandes melhorias em todo o ecossistema. A descontinuação da biblioteca é apenas marcar a oportunidade para que outros verifiquem bibliotecas novas e mais modernas, em vez de simplesmente confiar nas mais populares que existem.

@mikeal, obrigado por todos os seus esforços na biblioteca ( r2 também) e no ecossistema. Além disso, para definir essa precedência de uma depreciação bem pensada e planejada no ecossistema.

Vamos apenas mudar a versão principal quando descontinuarmos. Dessa forma, a maioria das pessoas que dependem do projeto não verá esse erro até tentar fazer um upgrade para uma nova especialização, o que significa que estão desenvolvendo ativamente e realmente devem procurar uma alternativa.

@mikeal Não acho que seja uma boa ideia.

O problema é que a maioria das substituições tem qualidade inferior à solicitada. Acabei de me mudar para request de axios cerca de uma semana atrás.

Axios tem bugs persistentes de vários anos em torno do suporte de proxy, modificando agentes https e exceções de promessa não tratadas. Você só descobre isso depois de investir pesadamente em axios.

Para novos usuários, axios parece superficialmente tão bom quanto uma solicitação (número semelhante de usuários, promessas de design, etc)

Obrigado por request :)

Se alguém estiver procurando por uma biblioteca HTTP mínima baseada em promessa com filtros plugáveis ​​e bom suporte para streams, você pode verificar o site httplease . Nós o usamos há alguns anos em produção.

Eu amo o módulo de solicitação. Muito obrigado.
Quer dizer que a solicitação recebe muito foco para evitar que outro mesmo módulo seja lançado?

Se houver bugs específicos em recursos comparáveis ​​em outras bibliotecas, gostaria de identificá-los especificamente. O suporte a proxy é um recurso complexo e ter um caso de teste em que a solicitação passa, mas outras bibliotecas falham é muito valioso.

@reconbot no último axios (^ 0.18.0), você não pode se conectar a um site https por meio de um servidor proxy. fazer isso resulta em EPROTO erros. este é um bug aberto em relação a isso, mas o problema remonta a anos: https://github.com/axios/axios/issues/1981

editar: especificamente, você não pode usar axios para fazer solicitações https por meio de um proxy http. talvez um proxy https dedicado funcione, não tentei.

Espero que as correções não sejam consideradas novos recursos, como minha solicitação de pull para Tamanho Máximo de Resposta, que vejo como um recurso padrão obrigatório de qualquer biblioteca madura.

Além disso, eu revisei outras bibliotecas de solicitação antes de escolher esta e a maioria delas são muito problemáticas, incompletas e cheias de bugs. Seus documentos também não medem. Eu realmente não vejo o que outra biblioteca pode trazer, exceto código não testado e bugs, não é como se houvesse uma nova abordagem para fazer solicitações HTTP. É tudo uma questão de empacotar o módulo http / https e fornecer padrões sãos, como resposta de buffer, respostas de decodificação e, claro, a capacidade de prometir a coisa toda . O maior problema dessa biblioteca aqui é o objetivo de compatibilidade total, tentar ser compatível com coisas legadas só traz dor e práticas de codificação legadas. Mas isso pode ser corrigido de várias maneiras. Existe uma boa base que pode ser refatorada em algo elegante, moderno e minimalista. E, acima de tudo, confiável. Há muitas maneiras de fazer isso - dividir em mais arquivos, usar ECMA6 com Babel ou Typescript.

Nenhum desenvolvedor lógico deseja 10 bibliotecas que fazem a mesma coisa, mas carecem de recursos diferentes, são cheias de erros e não documentadas. Esta biblioteca realmente funciona e eu sou grato por ela e espero que não esteja obsoleta, mas sim revivida.

Correções não são consideradas novos recursos. As correções serão mescladas por pelo menos um ano, possivelmente até mais.

-Mikeal


De: mivanovaxway [email protected]
Enviado: quinta-feira, 11 de abril de 2019 02:38
Para: solicitar / solicitar
Cc: Mikeal Rogers; Menção
Assunto: Re: [solicitação / solicitação] Solicitação de passado, presente e futuro (# 3142)

Espero que as correções não sejam consideradas novos recursos, como minha solicitação de pull para Tamanho Máximo de Resposta, que vejo como um recurso padrão obrigatório de qualquer biblioteca madura.

Além disso, eu revisei outras bibliotecas de solicitação antes de escolher esta e a maioria delas são muito problemáticas, incompletas e cheias de bugs. Seus documentos também não medem. Eu realmente não vejo o que outra biblioteca pode trazer, exceto código não testado e bugs, não é como se houvesse uma nova abordagem para fazer solicitações HTTP. É tudo uma questão de empacotar o módulo http / https e fornecer padrões sãos, como resposta de buffer, respostas de decodificação e, claro, a capacidade de prometir a coisa toda. O maior problema dessa biblioteca aqui é o objetivo de compatibilidade total, tentar ser compatível com coisas legadas só traz dor e práticas de codificação legadas. Mas isso pode ser corrigido de várias maneiras. Existe uma boa base que pode ser refatorada em algo elegante, moderno e minimalista. E, acima de tudo, confiável. Há muitas maneiras de fazer isso - dividir em mais arquivos, usar ECMA6 com Babel ou Typescript.

Nenhum desenvolvedor lógico deseja 10 bibliotecas que fazem a mesma coisa, mas carecem de recursos diferentes, são cheias de erros e não documentadas. Esta biblioteca realmente funciona e eu sou grato por ela e espero que não esteja obsoleta, mas sim revivida.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/request/request/issues/3142#issuecomment-482043697 ou desative o thread https://github.com/notifications/unsubscribe-auth/AAACQ8I4BSRtOjqHk637gRfBhkvGbRrIks5JfBhkvGbRrIks5

Os pacotes TIL 41k tornaram-se vulneráveis.

Olha, eu concordo que a solicitação deve ser eliminada, mas sempre tenho medo de que pacotes convencionais como esse mudem seu pipeline de lançamento. Um malfeitor ou uma caixa de desenvolvimento comprometida publicando código malicioso se espalharia efetivamente para todos os projetos por aí.

Considere apertar os requisitos de push npm. Configure um branch para ci, exija várias aprovações, algo mais do que simplesmente enviar para o master.

sem promessas embora.

Trocadilho pretendido? 🤣

talvez o mesmo raciocínio lógico deva ser aplicado a expressjs? para solicitação, agora temos o novo módulo brilhante obtido, não há nenhuma reescrita ou alternativa verdadeira para expressjs no horizonte.

Express é ótimo, mas não é realmente atualizado ativamente com novos recursos nestes anos

O express pode não ser atualizado com novos recursos, mas é mantido ativamente e, da última vez que verifiquei, algumas pessoas ainda estão bastante interessadas em fazer esse trabalho. não sei se eles precisam seguir as etapas que tomamos em relação à suspensão de uso.

@laoshaw, o que expressa alguma coisa a ver com request ?

Preparando a suspensão total. https://github.com/request/request/pull/3267

Estamos totalmente obsoletos!

Todas as versões em npm observam a depreciação e o README observa claramente que request foi descontinuado.

Foram mais de 10 anos ótimos, graças a todos que contribuíram na última década. Vamos todos esperar por novas bibliotecas que sejam mais adequadas para as mudanças que estão ocorrendo na linguagem JS e no ecossistema.

Então, vamos ser ESPECÍFICOS.
Qual é a substituição de código enxuto para o módulo de solicitação?

Para não ficar pendurado na crosta morta ... tantas opções melhores ... como QUAIS?
GRAND não faz tudo sob as bibliotecas / módulos sun, por favor.

@riclf , estamos usando https://github.com/googleapis/teeny-request/ para nos ajudar a sair da solicitação por alguns anos. Ele não faz tudo o que você gostaria que ele fizesse :) Ele usa node-fetch sob o capô. Existem outras ótimas opções por aí também!

Para uma solução que promete primeiro, também há gofer que é fortemente focado na comunicação de API. Suporte para tempo limite de conexão TCP integrado, configuração fácil (e erros ricos) para falar com várias APIs, etc.

Alguém tem alguma recomendação para clientes alternativos que tenham bom suporte para HTTP Long Polling e se apresentem como um Stream ou Event Emitter?

A última vez que verifiquei em abril de 2019, alternativas como got , node-fetch e axios tiveram um grande problema: quando um erro (rede de baixo nível) aconteceu, eles descartaram o rastreio de pilha útil relatado pelo núcleo Node.js e gerou um novo erro de alto nível com um rastreio de pilha apontando apenas para a biblioteca cliente http. Isso tornou a depuração de problemas de nível de transporte praticamente impossível, por exemplo, quando proxies estão envolvidos.

Existe alguma boa alternativa request que preserva os detalhes do erro fornecidos pelo núcleo do Node.js.

@bajtos Tenho certeza de que gofer apenas decora os erros originais, mas deve preservar os rastreamentos de pilha e as mensagens.

bent tem erros legais e é projetado para assíncrono / espera. Também é incrivelmente pequeno e o tamanho do pacote é minúsculo;)

A API não é nada parecida com a solicitação, então eu não a chamaria de "substituição".

@mikeal Por que é chamado de bent ? (pedido era um nome mais fácil de lembrar.)

bent tem erros legais e é projetado para assíncrono / espera. Também é incrivelmente pequeno e o tamanho do pacote é minúsculo;)

A API não é nada parecida com a solicitação, então eu não a chamaria de "substituição".

Isso parece muito mais com uma lógica tecnicamente correta do que uma lógica amigável. Do ponto de vista do usuário, o bent resolve o mesmo problema que o pedido, mas melhor. Agora está preso com um nome pior sem motivo. Você pode chamá-lo de pedido 3 sem muito problema. Sim, a API está quebrando, mas é o que temos semver.

Você pode chamá-lo de pedido 3 sem muito problema. Sim, a API está quebrando, mas é o que temos semver.

Passe algum tempo com bent e você pode se sentir diferente.

Não é uma pequena diferença na nomenclatura ou promessas versus retornos de chamada. A ergonomia é muito diferente, os estados de superfície são muito diferentes, a maneira como ele pensa sobre as condições de erro é uma abordagem radicalmente diferente.

request é uma API mais procedural, você diz a ela para fazer algo e ela diz o que aconteceu, só dá um erro se algo falhar irremediavelmente. bent pega os critérios de sucesso para todo o ciclo de vida e retorna uma API que irá falhar se qualquer coisa, mas os critérios de sucesso forem atendidos .

Você usa essas bibliotecas de maneira muito diferente. Existem outras bibliotecas que estão mais perto da API de request se isso é o que você deseja, mas depois de quase 20 anos trabalhando em clientes HTTP, descobri uma abordagem diferente e, em última análise, melhor que encorajaria as pessoas considerar, mas não vou enfiar na garganta de todos tornando-o request 3.0.

Por que é chamado de dobrado? (pedido era um nome mais fácil de lembrar.)

Porque você o “dobra” em uma forma específica (critérios de sucesso muito específicos) e fornece uma API ideal para o sucesso dessa forma e falha em qualquer coisa, exceto nela.

O nome é um pouco abstrato, mas request é o tipo de nome que você nunca poderia ter hoje. Eu mal consegui request no registro npm e escrevi o registro npm original 😜

que tal "obtido" como um substituto, é triste não termos um substituto claro enquanto a solicitação está oficialmente obsoleta.

que tal "obtido" como um substituto, é triste não termos um substituto claro enquanto a solicitação está oficialmente obsoleta.

Talvez devêssemos considerar o fato de que ninguém escreveu uma substituição compatível com a API como uma indicação de que adotar uma substituição compatível com a API é indesejável depois de sentar e trabalhar nisso 🧐

Essa foi certamente a minha experiência.

Talvez o que as pessoas realmente queiram quando pedem uma "substituição" não seja tanto uma alternativa compatível com a API, mas a perspectiva do mantenedor sobre quais outros pacotes já existem para resolver aproximadamente o mesmo problema e que estão tornando este pacote irrelevante para que você pode chamá-lo com segurança de "obsoleto".

E eu diria que anunciar bent no aviso de suspensão de uso (possivelmente junto com alguns outros, se isso o deixar mais confortável) é uma ótima maneira de começar a divulgá-lo, apesar da nomenclatura obscura.


Módulo de solicitação Angluar 8 obsoleto

npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
npm ERR! code E404
npm ERR! 404 Not Found: error-ex@^1.3.1

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\Ammar\AppData\Roaming\npm-cache\_logs\2020-02-12T04_18_22_538Z-debug.log

Você realmente entende o que "obsoleto" realmente significa?

Descontinuada. No mundo do desenvolvimento de software, "obsoleto" refere-se a funções ou elementos que estão em processo de substituição por outros mais novos. O termo vem da palavra "desaprovar", que significa desaprovar algo.

Na prática, isso significa que, quando mantenho qualquer um dos meus módulos (não de código aberto), recebo mensagens de erro bobas.

E quanto aos 151 problemas e 55 solicitações de pull? Despejá-los?

E eu diria que a publicidade inclinada no aviso de reprovação (possivelmente com outras pessoas, se isso o deixar mais confortável) é uma ótima maneira de começar a divulgá-la, apesar da nomenclatura obscura.

Isso é MUITO cedo - veja a edição 2 de bent.

Acho que essa solicitação deve entrar em um modo de limbo - não obsoleto, o que causa avisos tolos - mas onde NADA será realizada, todos os problemas e puxões serão ignorados e a página README deve ser atualizada para observar isso e, quando apropriado, as referências serão incluído em outros pacotes funcionalmente equivalentes.

E quanto aos 151 problemas e 55 solicitações de pull? Despejá-los?

Ninguém está corrigindo ou revisando isso há algum tempo, eles foram “descartados”.

Seus comentários fazem parecer que há algum tipo de trabalho dedicado neste projeto ao qual as pessoas têm direito. Isso nunca foi o caso, request não é um produto lançado e apoiado por uma empresa, ele sempre foi mantido por desenvolvedores de código aberto que se preocupam e como o ecossistema mudou em uma nova direção, todos nós mudamos com ele . Eu recomendo que você siga em frente também.

Ninguém está corrigindo ou revisando isso há algum tempo, eles já foram “descartados”.

O que você quer dizer é que VOCÊ não os analisa há algum tempo. Seja justo, nós que não somos colaboradores não temos controle sobre isso.

Seus comentários fazem parecer que há algum tipo de trabalho dedicado neste projeto ao qual as pessoas têm direito.

Eu não quis dizer isso, mas em certo sentido é verdade, o software de código-fonte aberto concede certos direitos ao usuário, bem como protege os direitos do desenvolvedor. Esses direitos são de uso, não de manutenção. Quando a manutenção ou o desenvolvimento futuro envolve mudanças bruscas, muito cuidado e reflexão devem ser tomados. Esta é uma alteração significativa e, na minha opinião, desnecessária. Deixe o módulo como está e todos seguiremos para o próximo projeto - principalmente se a alternativa oferecer vantagens. Na verdade, seríamos tolos se não o fizéssemos. Mas, até onde posso ver, não há alternativa real no momento.

O software de código aberto concede certos direitos ao usuário

As licenças OSS fornecem direitos para redistribuir e modificar, nenhuma garantia de qualquer tipo é feita sobre a adequação do software para qualquer uso específico. Nenhuma garantia é feita sobre alterações futuras, incluindo possíveis alterações de interrupção.

Aqui está o texto relevante da licença Apache 2. Quase toda licença de código aberto tem isso.

“Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.”

Esta é uma alteração significativa e, na minha opinião, desnecessária. Deixe o módulo como está e todos seguiremos para o próximo projeto - principalmente se a alternativa oferecer vantagens. Na verdade, seríamos tolos se não o fizéssemos. Mas, até onde posso ver, não há alternativa real no momento.

Aqui está a coisa. Este código tem bugs conhecidos que não serão corrigidos. Este código não é mais mantido e está obsoleto.

O aviso de descontinuação é um aviso de que você está contando com um código problemático. Se você está bem contando com um código obsoleto e problemático, simplesmente suprima as mensagens. Seu problema parece ser os avisos e não o estado do software. Se você estiver de acordo com o estado do software, simplesmente suprima os avisos.

Não alteraremos o estado de descontinuação e os avisos relevantes para que fiquem fora da realidade, a fim de satisfazer a preocupação de qualquer usuário em particular sobre os avisos que eles podem facilmente suprimir se não estiverem preocupados em depender de módulos obsoletos.

preciso de ajuda !!! .. Estou tendo esses problemas quando tento instalar o node-gyp 3.6.2
PS C: \ Usuários \ Usuário> npm install --global [email protected]
npm WARN deprecated [email protected] : a solicitação foi descontinuada, consulte https://github.com/request/request/issues/3142
npm ERR! caminho C: \ Users \ User \ AppData \ Roamingnpm \ node-gyp.cmd
npm ERR! código EEXIST
npm ERR! Recusar-se a excluir C: \ Users \ User \ AppData \ Roamingnpm \ node-gyp.cmd: está fora de C: \ Users \ User \ AppData \ Roamingnpm \ node_modules \ node-gyp e não é um link
npm ERR! O arquivo existe: C: \ Users \ User \ AppData \ Roamingnpm \ node-gyp.cmd
npm ERR! Afaste-o e tente novamente.

npm ERR! Um registro completo desta execução pode ser encontrado em:
npm ERR! C: \ Users \ User \ AppData \ Roamingnpm-cache_logs \ 2020-02-13T05_12_13_683Z-debug.log

@mikeal Oh, este é um caso interessante. Ter o número do problema no aviso de descontinuação pode trazer muitos comentários não relacionados aqui, como @Meharab demonstrou.

Talvez seja hora de evitar mais comentários aqui?

ATUALIZAÇÃO : 5 dias depois e os comentários estão realmente se acumulando.

@mikeal Obrigado por esses anos

Pedido de boa noite. Vejo você do outro lado.

a solicitação vai funcionar para sempre (como está), porque isso é JavaScript ... bem, a menos que o Node introduza uma mudança significativa ao descontinuar uma API principal usada por ele

a solicitação vai funcionar para sempre (como está), porque isso é JavaScript ... bem, a menos que o Node introduza uma mudança significativa ao descontinuar uma API principal usada por ele

Não.
Este código tem bugs conhecidos que não serão corrigidos. Este código não é mais mantido e está obsoleto. (cit.)

Portanto, a solicitação terá bugs não corrigidos para sempre não funcionará para sempre ...

Eu não entendo. Então, o que devo fazer oficialmente agora, para não receber o aviso de suspensão de uso?

Remova request . Isso pode envolver removê-lo de suas próprias dependências, atualizar pacotes que o removem em versões mais novas ou remover pacotes que ainda não foram atualizados com versões mais recentes.

Olá.

Estou tentando instalar o Cordova.

npm install -g cordova

Eu continuo recebendo esse erro.
Microsoft Windows [Versão 10.0.18362.592]
(c) 2019 Microsoft Corporation. Todos os direitos reservados.

C: \ Usuários> npm install -g cordova
npm WARN deprecated [email protected]: a solicitação foi descontinuada, consulte https://github.com/request/request/issues/3142
C: \ Users \ AppData \ Roamingnpm \ cordova -> C: \ Users \ AppData \ Roamingnpm \ node_modules \ cordova \ bin \ cordova

Existe outra maneira de instalar o Cordova?
Uma maneira de contornar essa compra?

sim. OK. Vou remover o pedido. Mas e então?

Então, em node.js, tenho que mudar para .. idk .. axios?

O que devo colocar no lugar do reqest?

Eu entendo que a ideia é reescrever todas as funções onde a solicitação estava presente?

Existe um pacote que eu poderia simplesmente alterar com localizar e substituir por regex?

Existe uma substituição oficial para o pedido ou estamos apenas liberados agora para encontrar o que surgir primeiro no Google? Eu não entendo

Existe uma substituição oficial para o pedido

Não, você pode usar o que quiser, embora o mesmo desenvolvedor esteja trabalhando em bent

Também existe o fork postman-request que recebeu várias correções, ~ mas não teve nenhuma atividade desde a depreciação de request . ~

Como eles não têm uma página de problemas, suponho que tentarei perguntar aqui:

@coditva @codenirvana @shamasis @vikiCoder @czardoz

Desculpas pelas menções, mas quais são os planos para postman-request agora que request está oficialmente morto? postman-request continuará sendo mantido ou será descontinuado?

preciso de ajuda!!! Estou tentando instalar o angular, estou com um problema
npm install -g @ angular / cli
npm WARN deprecated [email protected]: a solicitação foi descontinuada, consulte https://github.com/request/request/issues/3142
npm ERR! código EEXIST
npm ERR! caminho C: \ Users \ FARHAN \ AppData \ Roamingnpm \ node_modules \ @angular \ cli \ bin \ ng
npm ERR! dest C: \ Users \ FARHAN \ AppData \ Roamingnpm \ ng.cmd
npm ERR! EEXIST: arquivo já existe, cmd shim 'C: \ Usuários \ FARHAN \ AppData \ Roamingnpm \ node_modules \ @angular \ cli \ bin \ ng' -> 'C: \ Usuários \ FARHAN \ AppData \ Roamingnpm \ ng.cmd'
npm ERR! O arquivo existe: C: \ Users \ FARHAN \ AppData \ Roamingnpm \ ng.cmd
npm ERR! Remova o arquivo existente e tente novamente ou execute o npm
npm ERR! com --force para sobrescrever arquivos imprudentemente.

npm ERR! Um registro completo desta execução pode ser encontrado em:
npm ERR! C: \ Users \ FARHAN \ AppData \ Roamingnpm-cache_logs \ 2020-02-15T09_52_19_067Z-debug.log

Quais são as alternativas para request ? O Angular ainda depende disso. Espero que eles atualizem sua base de código em breve.

Eu tenho uma solução de curto prazo que Mikeal Rogers vai recuar, talvez até mesmo me atacar. Esta descontinuação atual veio em 2 fases não programadas - 1) uma discussão geral de sua necessidade, 2) BANG, com aviso prévio de 30 minutos e foi implementado. Todo o inferno começou.

Pergunto a @mikeal se ele consideraria reverter a

As 3 fases-
1) Discussão: 20 de março de 2019 a 15 de fevereiro de 2020
2) Aviso de suspensão de uso de 6 meses: 15 de fevereiro de 2020
3) Implementação da suspensão de uso: 15 de agosto de 2020

Dessa forma, não apenas os frameworks e projetos de aplicativos NÃO são quebrados instantaneamente, o que é muito difícil, mas esta comunidade agora pode usar ESTA área de discussão para compartilhar alternativas, os +/- nos próximos meses e colocar as alternativas no lugar até o prazo de 6 meses. Então, quando acontecer, todos podemos saudá-lo, gritar cheerio, e nada se quebra.

Por favor, entenda, eu não estou argumentando sobre a necessidade de sua suspensão de uso, ou o direito do criador de fazê-lo ... Estou sugerindo um cronograma de aviso prévio de 3 etapas, conforme declarado acima, que será responsável por sua própria uso significativo na comunidade de desenvolvedores e os aplicativos ativos no mundo hoje, dependendo do módulo de solicitação.

Mikeal, por favor, considere minha sugestão, remova o status de Suspensão hoje e anuncie o aviso de 6 meses. Menos de 6 meses não é tempo suficiente para muitos de nós, 6 é justo. Eu apreciaria isso, todos nós.

Muito obrigado por me ouvir,
-Ric Fink

Adicionar um aviso de descontinuação não interrompe nada, apenas avisa os usuários que pode ser interrompido no futuro. Prefiro ver uma mensagem de descontinuação antes de ter que esperar pela discussão da comunidade antes de saber que eventualmente terei que substituir um pacote.

Além disso, um lembrete amigável de que este pacote foi desenvolvido através de código aberto gratuitamente, e o mantenedor não deve nada a você. Se quiser continuar usando o pacote, você pode bifurcá-lo e continuar fazendo a manutenção por conta própria.

@riclf

preciso de ajuda!!! Estou tentando instalar o angular, estou com um problema
npm install -g @ angular / cli
npm WARN descontinuado [email protected]: o pedido foi descontinuado, consulte # 3142
npm ERR! código EEXIST
npm ERR! caminho C: \ Users \ FARHAN \ AppData \ Roamingnpm \ node_modules @ angular \ cli \ bin \ ng
npm ERR! dest C: \ Users \ FARHAN \ AppData \ Roamingnpm \ ng.cmd
npm ERR! EEXIST: arquivo já existe, cmd shim 'C: \ Usuários \ FARHAN \ AppData \ Roamingnpm \ node_modules @ angular \ cli \ bin \ ng' -> 'C: \ Usuários \ FARHAN \ AppData \ Roamingnpm \ ng.cmd'
npm ERR! O arquivo existe: C: \ Users \ FARHAN \ AppData \ Roamingnpm \ ng.cmd
npm ERR! Remova o arquivo existente e tente novamente ou execute o npm
npm ERR! com --force para sobrescrever arquivos imprudentemente.

npm ERR! Um registro completo desta execução pode ser encontrado em:
npm ERR! C: \ Users \ FARHAN \ AppData \ Roamingnpm-cache_logs \ 2020-02-15T09_52_19_067Z-debug.log

Isso parece ter sido resolvido com o lançamento mais recente do Angular, em que request é substituído por node-fetch .

@AURZeeshan
Seu erro não está relacionado a isso. Você está apenas vendo um aviso deste pacote, o erro é diferente.

@riclf

preciso de ajuda!!! Estou tentando instalar o angular, estou com um problema
npm install -g @ angular / cli
npm WARN descontinuado [email protected]: o pedido foi descontinuado, consulte # 3142
npm ERR! código EEXIST
npm ERR! caminho C: \ Users \ FARHAN \ AppData \ Roamingnpm \ node_modules @ angular \ cli \ bin \ ng
npm ERR! dest C: \ Users \ FARHAN \ AppData \ Roamingnpm \ ng.cmd
npm ERR! EEXIST: arquivo já existe, cmd shim 'C: \ Usuários \ FARHAN \ AppData \ Roamingnpm \ node_modules @ angular \ cli \ bin \ ng' -> 'C: \ Usuários \ FARHAN \ AppData \ Roamingnpm \ ng.cmd'
npm ERR! O arquivo existe: C: \ Users \ FARHAN \ AppData \ Roamingnpm \ ng.cmd
npm ERR! Remova o arquivo existente e tente novamente ou execute o npm
npm ERR! com --force para sobrescrever arquivos imprudentemente.
npm ERR! Um registro completo desta execução pode ser encontrado em:
npm ERR! C: \ Users \ FARHAN \ AppData \ Roamingnpm-cache_logs \ 2020-02-15T09_52_19_067Z-debug.log

Isso parece ter sido resolvido com o lançamento mais recente do Angular, em que request é substituído por node-fetch .

Instalei a versão CLI mais recente. Ainda lança o mesmo aviso

npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142

@ vighnesh153 Qual versão de @angular/cli é especificada em seu package.json? Parece que algumas das dependências precisam ser solicitadas, mas não o pacote base em si. Veja http://npm.anvaka.com/#/view/2d/% 2540angular% 252Fcli

Talvez você esteja certo. Não tenho certeza de qual dos pacotes está usando o pacote de solicitação. Aqui está um resumo dos departamentos:

"dependencies": {
    "@angular/animations": "~9.0.1",
    "@angular/common": "~9.0.1",
    "@angular/compiler": "~9.0.1",
    "@angular/core": "~9.0.1",
    "@angular/forms": "~9.0.1",
    "@angular/platform-browser": "~9.0.1",
    "@angular/platform-browser-dynamic": "~9.0.1",
    "@angular/router": "~9.0.1",
    "rxjs": "~6.5.4",
    "tslib": "^1.10.0",
    "zone.js": "~0.10.2"
  },
  "devDependencies": {
    "@angular-devkit/build-angular": "~0.900.2",
    "@angular/cli": "~9.0.2",
    "@angular/compiler-cli": "~9.0.1",
    "@angular/language-service": "~9.0.1",
    "@types/node": "^12.11.1",
    "@types/jasmine": "~3.5.0",
    "@types/jasminewd2": "~2.0.3",
    "codelyzer": "^5.1.2",
    "jasmine-core": "~3.5.0",
    "jasmine-spec-reporter": "~4.2.1",
    "karma": "~4.3.0",
    "karma-chrome-launcher": "~3.1.0",
    "karma-coverage-istanbul-reporter": "~2.1.0",
    "karma-jasmine": "~2.0.1",
    "karma-jasmine-html-reporter": "^1.4.2",
    "protractor": "~5.4.3",
    "ts-node": "~8.3.0",
    "tslint": "~5.18.0",
    "typescript": "~3.7.5"
  }

npm install
npm WARN deprecated [email protected] : a solicitação foi descontinuada, consulte https://github.com/request/request/issues/3142

quando eu quiser completar "npm install" em \ vue-devtools-dev, eu avisei sobre isso
como posso resolver isso?

Respeito totalmente sua decisão de rejeitá-lo e desejo o melhor para o futuro.

Quanto às pessoas que vêm ao tópico procurando por "então o que devo usar de agora em diante ??", got ou axios são o que você está procurando.

Patético. É hora de migrar para a busca de nó.

... exceto que você mesmo questiona se node-fetch é um bom substituto para request , ou mesmo mantido ativamente. De fato patético.

https://github.com/node-fetch/node-fetch/issues/668#issuecomment -586903934

A propósito, as pessoas que estão optando por node-fetch realmente precisam ter cuidado. Essa lib, embora ótima, tem seus próprios problemas graves de manutenção.

Patético. É hora de migrar para a busca de nó.

... exceto que você mesmo questiona se node-fetch é um bom substituto para request , ou mesmo mantido ativamente. De fato patético.

node-fetch / node-fetch # 668 (comentário)

Pelo menos node-fetch não está obsoleto. A depreciação total da solicitação causou problemas com os sistemas autobuild. Eu não entendo e não aceito essa mudança e, na minha opinião, uma simples nota explicando que a biblioteca não é mantida seria suficiente em vez de uma depreciação pesada. Por isso considero essa situação patética.

na minha opinião, uma simples nota explicando que a biblioteca não é mantida seria suficiente

Isso é exatamente o que um aviso de depreciação é: uma nota simples.

@asgetz tudo o que o npm faz é imprimir aquele aviso ao instalar um pacote obsoleto, todo o resto funciona exatamente como antes.

Estou tendo problemas com arquivos less.js que funcionam no github. Eles funcionam bem no PHP. Quando tentei colocar menos no comando, este aviso apareceu. Alguma ideia sobre qual é o problema?

Screen Shot 2020-02-14 at 1 37 08 PM

A solicitação

Existe uma substituição para request , mas com a interface de fluxo do node.js? Descobri que node-fetch , axios são ambos baseados em Promise .

Gostaria de saber um substituto para a interface de fluxo, que é mais conveniente para casos de uso de nível inferior.

@ maple3142 got tem uma interface de fluxo (assim como promessas) e um guia de migração .

@asgetz

O npm está indicando que devo instalá-lo sozinho agora.

É de que maneira está indicando isso. Quando eu instalo request , acabo de receber o aviso de descontinuação e tudo funciona como antes.

meu uso planejado para isso é tão pequeno

Nesse caso, talvez dê uma olhada na curvatura, que é muito mais leve e parece funcionar bem.

@mikeal, você pode dar uma olhada em https://github.com/request/request/pull/3245 proxyHeaderExclusiveList é um dos melhores recursos neste pacote e não está funcionando corretamente.
Vamos consertar isso!

@kauegimenes este pacote está obsoleto ... nada será consertado nunca mais

@kevinvanrijn Não estou mais ativamente envolvido na manutenção de postman-request , mas o projeto está definitivamente vivo e o último lançamento foi há um mês. No entanto, vou deixar os mantenedores ativos opinarem sobre os planos de longo prazo.

@czardoz É bom saber. Eu tenho um monte de pequenos projetos (todos privados) dependendo de request que não posso perder tempo reescrevendo. Colocar postman-request em substituição significa que posso confiar que eles continuarão funcionando por um pouco mais de tempo.

cloudscraper também está sofrendo de manutenção lenta e provavelmente não será capaz de sair de request ainda. Ter postman-request disponível como uma opção significa que pelo menos não corre o risco de se tornar obsoleto.

@ Edo78 por que você diz isso? Eu ainda tenho fé que um dia meu RP será mesclado 😆

Os committers que ainda estão ativos tentarão mesclar as correções em tempo hábil, mas sem promessas.

Aliás, as pessoas que estão optando pelo node-fetch realmente precisam ter cuidado. Essa lib, embora ótima, tem seus próprios problemas graves de manutenção.

@csvan Você pode explicar um pouco? Estou vendo apenas alguns problemas

Eu sei muito pouco sobre npm. Usei para instalar uma API e recebi alguns avisos que não entendi. Eles me direcionam aqui. Isso é totalmente inútil para mim. Alguém deve postar algo aqui que seja útil para aqueles de nós direcionados aqui ou a mensagem no npm deve ser corrigida para ser mais útil. A seguir estão as mensagens que recebi.

npm WARN deprecated [email protected] : a solicitação foi descontinuada, consulte https://github.com/request/request/issues/3142
npm WARN saveError ENOENT: nenhum arquivo ou diretório, abra 'C: \ Users \ Sam \ package.json'
O aviso npm criou um arquivo de bloqueio como pacote-lock.json. Você deve enviar este arquivo.
npm WARN enoent ENOENT: nenhum arquivo ou diretório, abra 'C: \ Users \ Sam \ package.json'
npm WARN Sam Sem descrição
npm WARN Sam Nenhum campo de repositório.
npm WARN Sam Sem dados README
npm WARN Sam Nenhum campo de licença.

Além disso, não há arquivo package.json, mas há um package-lock.json. Não tenho ideia do que procurar lá.

@SimpleSamples o pacote está obsoleto e não será mantido ativamente à parte de possíveis correções de bugs, como o texto explica claramente. O NPM está simplesmente avisando que você está usando um pacote obsoleto, para que você tenha a oportunidade de mudar para outro.

Se você não entende o que significa descontinuação, existem vários artigos úteis a uma pesquisa do Google.

Sim, eu entendo o que significa suspensão de uso e, portanto, o link para o
a discussão do Passado, Presente e Futuro da Solicitação não fornece qualquer
esclarecimento, apenas adiciona confusão. Ou há algo mais que eu faço
não entendeu e você não está esclarecendo? Se for apenas dizer isso
A solicitação está obsoleta, então é tudo o que ela precisa dizer, em vez de
implicando que há algo mais que devemos fazer.

Seria muito útil se dissesse (link para um artigo
explicando) o que o substitui, ou qualquer ação da qual devemos estar cientes.

Christopher Svanefalk [email protected]
Terça-feira, 18 de fevereiro de 2020, 22h45

@SimpleSamples https://github.com/SimpleSamples o pacote é
obsoleto e não receberá mais atualizações, como o texto
explica claramente. O NPM está simplesmente avisando que você está usando um
pacote obsoleto.

Se você não entende o que significa suspensão de uso, existem vários
artigos úteis a uma pesquisa do Google.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/request/request/issues/3142?email_source=notifications&email_token=ACK22R4G7LHULMPO6DHH273RDTIP7A5CNFSM4HCP6LRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMGR4HI#issuecomment-588062237 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/ACK22R7UFQSYKW7NEYZ4OTDRDTIP7ANCNFSM4HCP6LRA .

Se estiver apenas dizendo que a solicitação está obsoleta, então é tudo o que ela precisa dizer

Sim, f * ck qualquer um que aprecia contexto e gosta de saber os motivos das decisões ou quer saber detalhes sobre a eliminação progressiva. : P
Falando sério, porém, se houvesse um acréscimo "por que" ao aviso, isso teria evitado sua confusão?

"npm WARN deprecated [email protected] : a solicitação foi descontinuada, consulte o nº 3142 para saber o

Você está certo. Eu não vi a parte "por que".

Espen escreveu:

"quanto ao porquê"

@SimpleSamples, desculpe se estou entendendo mal, mas eu realmente não vejo a confusão. A solicitação foi descontinuada e o texto deste problema explica claramente por que e o que isso implica.

De onde você tirou a ideia de que precisa fazer alguma coisa? Uma reprovação é apenas uma reprovação, como você lida com isso é com você.

Não há nada de errado com os usos de solicitação de padrões. Pelo contrário, existe uma enorme comunidade no ecossistema javascript que ainda usa esses padrões. Em minha experiência, é uma comunidade muito maior do que a minoria vocal (a maioria das grandes empresas), que tem os recursos para destruir constantemente as bases de código que funcionam perfeitamente por nada mais do que vaidade e arrogância do desenvolvedor.

Lamento que você tenha caído nesta armadilha. O pedido tem sido um grande serviço para a comunidade e espero sinceramente que você reconsidere sua decisão.

Sim, estou triste porque isso acabou. Retornos de chamada não são ruins, nem são promessas ou espera assíncrona.

Acho que o que está faltando em @SimpleSamples é que o restante dos avisos que você colou não têm nada a ver com o aviso de descontinuação que o trouxe aqui. Você não precisa fazer nada sobre a depreciação, mas pode querer fazer algo sobre a falta de package.json (ou o que quer que esteja causando esses outros avisos).

Então, o que devemos fazer agora com todos esses pacotes que estão usando request sob o capô?

Tentei substituir request por @root/request em um desses pacotes, presumindo que fosse realmente uma substituição imediata, mas não consegui fazer funcionar .

Também tentei substituir request por algo como ...

const httprequest = require('http').request; const httpsrequest = require('https').request;

... e...

const request = parsedUrl.protocol === 'http' ? httprequest : httpsrequest`

... mas também não consegui fazer funcionar.

Então, e agora? Na ausência de uma substituição instantânea que realmente cumpra sua promessa, devemos todos viver com várias dependências em nosso node_modules que dependem de um pacote obsoleto, vários dos quais não parecem ser mantida? E porque?

Eu percebi que request ficou desatualizado em vários aspectos, mas ao descontinuar este pacote sem oferecer uma substituição drop-in adequada, os módulos 41K agora dependem diretamente de um pacote descontinuado. Se considerarmos os pacotes que usam pelo menos um desses módulos de 41K como uma dependência, podemos estar falando de centenas de milhares, senão milhões de pacotes que são afetados.

Claro, acho que para alguns pacotes, é fácil substituir request por algo como fetch , axios , superagent ou http.request nativo do Node.js https.request . Mas, por exemplo. no caso em que as solicitações são canalizadas para outra solicitação (como com html2canvas-proxy ), tenho dificuldade para descobrir o que diabos está acontecendo lá ... e realmente não posso gastar muitas horas tentando substituir apenas algumas linhas de código obsoleto enquanto eu deveria estar fazendo coisas mais importantes.

Sempre me cansei de depender demais de uma infinidade de pacotes interdependentes que são carregados em segundo plano com um gerenciador de pacotes. Sim, suponho que isso pode descarregar muito do trabalho pesado para terceiros, mas em vez disso, você terá um monte de outras dores de cabeça para lidar.

Os gerenciadores de pacotes nos dão uma falsa sensação de segurança. Todo o desastre do leftpad há 4 anos parece não ter aberto os olhos das pessoas com relação aos riscos envolvidos. Tenho certeza de que isso também não fará diferença. Ainda assim, sinto que devo enfatizar que há algo muito errado quando um pacote obsoleto ou quebrado pode impactar milhões de pacotes em todo o ecossistema. E é provável que isso só piore, à medida que mais e mais projetos forem abandonados, obsoletos ou mesmo quebrados com o passar do tempo, e todos estaremos vivendo no inferno da dependência ...

Mas ei ... Acho que pelo menos isso significa que sempre haverá uma demanda para os desenvolvedores JS para limpar a bagunça $% # @ ...

@jslegers

Ainda assim, sinto que devo enfatizar que há algo muito errado quando um pacote obsoleto ou quebrado pode impactar milhões de pacotes em todo o ecossistema.

A única coisa errada é o pânico de que você e outras pessoas parecem estar sofrendo. leftpad foi embora, excluído. Isso não pode acontecer agora. A solicitação simplesmente foi descontinuada; não vai a lugar nenhum. Se funcionar agora, continuará a funcionar da mesma maneira.

Não há impacto em milhões de pacotes, a menos que você conte um aviso benigno.

Também tentei substituir a solicitação por algo como ...

Por favor, pare de entrar em pânico; pare de tentar consertar um problema inexistente. Use os pacotes que quiser: a depreciação do request não vai quebrá-los. Gradualmente, os mantenedores de seus pacotes podem mudar para outro pacote. Ou talvez não. Não importa. Nada mudou, a não ser o aparecimento de uma pequena mensagem.

sempre haveria uma demanda para desenvolvedores JS para limpar a bagunça $% # @ ...

Não há bagunça. Apenas progresso.

Não há impacto em milhões de pacotes, a menos que você conte um aviso benigno .

Obsoleto, por exemplo. uma parte de sua API ou biblioteca significa basicamente que você a designa oficialmente como "obsoleta" e incentiva ativamente os usuários a optar por outra coisa.

A suspensão de uso é normalmente usada como um estágio intermediário entre o suporte oficial de algo e a suspensão oficial do suporte para algo, para dar aos desenvolvedores tempo para substituir o que quer que você tenha tornado obsoleto até que esse item não esteja mais disponível ou seja compatível com versões anteriores.

Os avisos de suspensão de uso devem deixá-lo nervoso. Eles pretendem ser um apelo à ação. Basicamente, o ponto de descontinuação é oferecer aos desenvolvedores um “período de carência”, permitindo que eles atualizem seu código antes que alguém desligue.

E não devem ser usados ​​para nenhum outro propósito. A suspensão de uso não deve apenas informar seus usuários que "Nossa API não segue os padrões de codificação mais recentes" ou "Não tenho mais tempo para manter este projeto" ... mesmo que a biblioteca seja bastante estável e bonita seguro para uso em + 99% de todos os casos de uso e provavelmente continuará funcionando bem por pelo menos a próxima década ou mais. Não é isso que depreciação significa, e usar avisos de depreciação apenas para expressar uma mensagem como essa cria um péssimo precedente IMO.

Além disso, é simplesmente feio ter seus npm install logs cheios de avisos de depreciação. Parece desleixado. É uma espécie de sinalizador vermelho e cria uma má primeira impressão para as pessoas que experimentam sua biblioteca ou estrutura. Especialmente se as pessoas estão realmente pagando para você usar sua biblioteca / estrutura, você deseja dar a elas um processo de instalação agradável / limpo com nenhum aviso.

Nada mudou, a não ser o aparecimento de uma pequena mensagem.

Essa pequena mensagem parece desleixada e supõe-se que não tenha outro propósito a não ser como uma chamada à ação ... uma chamada para substituir um pacote obsoleto por outra coisa.

Isso pode não importar para você, mas definitivamente é importante para mim e outras pessoas lá fora.

Não há bagunça. Apenas progresso.

Acho que você é uma daquelas pessoas que não sabe a diferença entre mudança e progresso.

De qualquer maneira, notei outras sugestões nos comentários do uso de postman-request . Ao contrário de @root/request , aquele parece funcionar como um substituto imediato, então irei atualizar todos os meus pacotes com este por enquanto ...

Acho que o que está faltando em @SimpleSamples é que o restante dos avisos que você colou não têm nada a ver com o aviso de descontinuação que o trouxe aqui. Você não precisa fazer nada sobre a depreciação, mas pode querer fazer algo sobre a falta de package.json (ou o que quer que esteja causando esses outros avisos).

Touché!

O ponto foi feito, mas os ataques pessoais continuam. Vocês são muito inteligentes e altamente capazes tecnicamente, mas há espaço para melhorias na experiência pessoal.

O ponto foi feito, mas os ataques pessoais continuam. Vocês são muito inteligentes e altamente capazes tecnicamente, mas há espaço para melhorias na experiência pessoal.

Ser inteligente, infelizmente, não impede que as pessoas deixem suas emoções obscurecerem seus julgamentos ... especialmente quando suas coisas acontecem como coisas ficando obsoletas aparentemente sem um bom motivo ou um consenso geral sobre qual é o propósito da depreciação.

De qualquer forma, acho que deixei bem claro meu ponto de vista. Eu gostaria de terminar encorajando @mikeal , @reconbot ou qualquer outro mantenedor deste projeto a propor oficialmente postman-request como um substituto completo para request e possivelmente @root/request para aqueles que precisam apenas de um subconjunto limitado de request e não se importam, por exemplo. córregos. Isso permite que qualquer mantenedor de pacote elimine request e se livre da mensagem de depreciação irritante sem gastar mais do que alguns minutos de tempo de desenvolvimento neste problema e sem ter que refatorar toda a sua biblioteca ou aplicativo.

@mikeal vindo da realidade do pedido ter sido descontinuado, eu gostaria de pedir a você um momento de reflexão que será útil para alguns ou talvez muitos de nós. Você tem 2 módulos de solicitação http posteriores, subsequentes à solicitação: r2 e bent.

Peço que nos dê um breve resumo das diferenças, benefícios e vantagens ou desvantagens de mudar para uma de suas substituições de solicitação, em vez de outra. Eu confio no seu trabalho.

Obrigado por este tempo, e posso ter certeza de dizer Obrigado pelos anos do módulo de solicitação.

-Ric

request-promise-native também está obsoleto ou é a coisa certa a se usar?

[email protected] : o pedido foi duplicado .... incapaz de criar um novo projeto

[email protected] : o pedido foi duplicado .... incapaz de criar um novo projeto

Você pode criar um projeto como sempre. O NPM está simplesmente avisando.

Por que este projeto foi excluído?

Sim, isso é bom

Usado por 4.476.352 Repositórios, 52.377 Pacotes.
Diga adeus à lenda.

Por que este projeto foi excluído?

@jleppert , não foi, por favor, leia o problema que você está comentando.

Tentei instalar o angular no linux e depois no windows e em ambos não consegui, após executar o comando npm install -g @ angular / cli @ latest em ambos apareceu este erro

C: \ Usuários \ Hanzell> npm install -g @ angular / cli @ mais recente
npm WARN deprecated [email protected]: a solicitação foi descontinuada, consulte https://github.com/request/request/issues/3142
C: \ Users \ Hanzell \ AppData \ Roamingnpm \ ng -> C: \ Users \ Hanzell \ AppData \ Roamingnpmnode_modules \ @angular \ cli \ bin \ ng

@ angular / [email protected] postinstall C: \ Users \ Hanzell \ AppData \ Roamingnpmnode_modules \ @angular \ cli
node ./bin/postinstall/script.js

Então, eu criei o repositório e este apareceu

C: \ Users \ Hanzell \ Desktop> ng new
? Que nome você gostaria de usar para o novo espaço de trabalho e projeto inicial? olá
? Você gostaria de adicionar o roteamento angular? Não
? Qual formato de folha de estilo você gostaria de usar? CSS
CRIAR hola / angular.json (3551 bytes)
CRIAR hola / package.json (1281 bytes)
CRIAR hola / README.md (1021 bytes)
CRIAR hola / tsconfig.json (543 bytes)
CREATE hola / tslint.json (1953 bytes)
CRIAR hola / .editorconfig (246 bytes)
CRIAR hola / .gitignore (631 bytes)
CRIAR hola / lista de navegadores (429 bytes)
CRIAR hola / karma.conf.js (1016 bytes)

npm ERR! Um registro completo desta execução pode ser encontrado em:
npm ERR! C: \ Users \ Hanzell \ AppData \ Roamingnpm-cache_logs \ 2020-03-01T05_15_55_441Z-debug.log
× Falha na instalação do pacote, veja acima.
O fluxo de trabalho esquemático falhou. Veja acima.
CRIAR hola / src / assets / .gitkeep (0 bytes

ajuda!

@RiveraHan os problemas que você está tendo não estão relacionados ao fato de request ter sido descontinuado.

Dito isso, eu estava curioso. Embora eu não use o angular desde seus dias de JS, tentei. Observe que eu não queria adicionar o CLI angular aos meus módulos globais, então procedi de maneira um pouco diferente. Testei o seguinte com npm 6.14.1 , node 12.16.1 e Debian GNU / Linux.

mkdir wrk-dir
cd wrk-dir
mkdir w1
cd w1
npm init -y
npm install @angular/cli --save-dev # this puts `ng` in `wrk-dir/w1/node_modules/.bin/ng`
cd ..
w1/node_modules/.bin/ng new my-app
cd my-app
../w1/node_modules/.bin/ng serve --open # browser will open with compiied results

Se você instalar o angular cli globalmente, apenas remova ../w1/node_modules/.bin/ e w1/node_modules/.bin/ do ng acima deve ser encontrado globalmente.

@millette Não funcionou no Linux ubuntu e windows 10. É a primeira vez que instalo o angular

@RiveraHan não é um erro. é um aviso NPM. Se qualquer configuração que você usar falhar nos avisos do npm, você precisará verificar a configuração para ela.

@csvan Mas, percebi ao abrir o novo projeto no meu editor de código que a pasta node_modules não aparece e faço uma pequena pesquisa para gerar a pasta node_modules novamente e é com o comando npm install que eu faço e o mesmo aparece outro erro .

@RiveraHan sim, mas novamente isso não tem nada a ver com request ou avisos npm - npm não interromperão a instalação a menos que seu ambiente de desenvolvimento esteja de alguma forma configurado para isso. Você precisa descobrir por que seu ambiente não tolera avisos do npm e o que você pode fazer a respeito - se esse for mesmo o problema no seu caso. Pode muito bem ser algo completamente diferente.

@ anton-bot, então ofereça-se para assumir o projeto e colocar todo o trabalho que os mantenedores atuais não têm tempo para fazer. É muito arrogante dizer aos outros como executar seus projetos se você não estiver disposto a se empenhar para que isso aconteça É código aberto.

@mikeal explicou claramente porque request está obsoleto. É a coisa responsável a fazer, é uma boa decisão e improvável que seja revertida.

Além disso, este:

Além disso, de forma realista, as pessoas não vão substituir seu código de trabalho perfeitamente bom que usa solicitação por outra coisa. Veja algumas das solicitações pull vinculadas - simplesmente não é uma ideia que as pessoas queiram fazer.

É por isso que acabamos com um código legado lixo que depende de módulos antigos que eram "códigos perfeitamente bons" em seus dias. Parte da manutenção de software é livrar-se de módulos antigos e obsoletos, substituindo-os por outros mantidos ativamente.

@ anton-bot Basta usar @root/request que é basicamente uma implementação compatível com 80% de request que usa APIs HTTP Node modernas sob o capô.

@ anton-bot Você está claramente perdendo vários fatos da vida:

  1. Este é um software de código aberto gratuito. Você não tem o direito de dizer aos mantenedores "Apenas parem com isso".
  2. A solicitação passou da data de validade (embora não tenha passado da data de validade). Tornou-se pesado e antiquado.
  3. @mikeal produziu pelo menos dois novos pacotes que substituem o pedido. Ambos são muito mais leves.
  4. Se você e outras pessoas desejarem continuar a usá-lo, você está livre para fazê-lo. Nada na suspensão de uso impede você de fazer isso.

Pessoalmente, aproveitei a oportunidade para atualizar gradualmente meus pacotes. O kraken-exchange , por exemplo, caiu de 5,9 MB para 284 KB instalados, mudando para bent .

@csvan disse que você era "bastante arrogante". Essa é uma frase muito mais polida do que eu teria usado.

@ anton-bot Basta usar @ root / request, que é basicamente uma implementação compatível com 80% da solicitação que usa APIs Node HTTP modernas sob o capô.

80% compatível não é bom o suficiente.

Eu uso dependências que dependem dos 20% ausentes (por exemplo, fluxos). Para isso, você precisa de uma substituição imediata com recursos completos, como postman-request .

Eu sugeri em um comentário anterior (que parece ter sido censurado / excluído) que os mantenedores entregou seu projeto para a equipe do carteiro, para que pudessem substituir request implementação 's com a implementação de postman-request , como aquele pacote ainda é mantido ativamente, completa de recursos e corrige alguns dos bugs nunca corrigidos em request .

Dessa forma, os autores originais de request poderiam dar um passo para trás e desfrutar de sua merecida "aposentadoria" sem assustar ou irritar um monte de gente ao depreciar request desnecessariamente.

Este é um software de código aberto gratuito. Você não tem o direito de dizer aos mantenedores "Apenas parem com isso".

Claro que sim. E da mesma forma, os mantenedores têm o direito de dizer "f * você".

A solicitação passou da data de validade (embora não tenha passado da data de validade). Tornou-se pesado e antiquado.

Ainda não é um motivo válido para o uso suspenso.

@mikeal produziu pelo menos dois novos pacotes que substituem o pedido. Ambos são muito mais leves.

Então?

Milhares de pacotes ainda estão usando request hoje e agora estão produzindo desnecessariamente avisos de depreciação durante npm install . Isso não deveria ter acontecido e poderia ser facilmente evitado, por exemplo. entregando a tocha para a equipe do Postman ou apenas deixando esse projeto morrer em paz.

Se você e outras pessoas desejarem continuar a usá-lo, você está livre para fazê-lo. Nada na suspensão de uso impede você de fazer isso.

Claro que sim.

Os clientes que ficam nervosos ao ver avisos de depreciação durante npm install impedem muitos de nós de simplesmente ficar de fora e não fazer nada.

Suspensão de uso = uma chamada à ação. Basicamente, ele dá às pessoas um período de tolerância para substituir suas dependências até que elas sejam interrompidas. Ele não deve ser usado em nenhum outro caso, mas nos casos em que se espera que as dependências interrompam a funcionalidade existente após o término de um período de cortesia.

Pessoalmente, aproveitei a oportunidade para atualizar gradualmente meus pacotes. O kraken-exchange, por exemplo, caiu de 5,9 MB para 284 KB instalados, mudando para bent.

Tentei substituir várias de nossas dependências por versões locais internalizadas / personalizadas desses pacotes e substituí request por request-postman para me livrar dos avisos de depreciação. Parecia uma solução fácil, que mais tarde nos permitiria substituir incrementalmente request-postman por uma alternativa mais leve.

Então eu aprendi que o NPM é incrivelmente problemático no que diz respeito ao manuseio com pacotes locais que dependem de pacotes locais, o que torna nosso ambiente significativamente menos estável. Isso abriu toda uma 'outra lata de minhocas, então eu tive que reverter minhas alterações e voltar para request , já que simplesmente não valia a pena o tempo e esforço para tentar corrigir esse tipo de problema neste momento ponto no tempo.

Por enquanto, não vejo outra alternativa a não ser conviver com os avisos de depreciação, já que simplesmente usamos muitas dependências que têm request como uma dependência para nos livrarmos delas com muito poucas dores de cabeça. Isso é lamentável e a IMO nunca deveria ter acontecido!

@csvan disse que você era "bastante arrogante". Essa é uma frase muito mais polida do que eu teria usado.

Quem é você para chamar uma pessoa de "arrogante" ou pior, só porque não consegue entender por que os avisos de depreciação são importantes para eles e seus projetos ?!

O que eu acho arrogante, é simplesmente descontinuar um projeto do qual milhões de outros projetos dependem sem nenhuma boa razão, em vez de procurar um mantenedor diferente para assumir as coisas de você. E considerando que a equipe do Postman já tem um fork completo de request que é mantido ativamente, não posso imaginar que teria sido muito difícil convencê-los a fazer isso.

Qual é sua estimativa, em milhões de dólares, do custo mundial desta decisão de depreciar request ?

Zero. Funciona tão bem como sempre. Simplesmente não vai ficar melhor.

Zero. Funciona tão bem como sempre. Simplesmente não vai ficar melhor.

Besteira!

Se você acha que os avisos de reprovação não têm impacto nos projetos que dependem deles, você não tem ideia do que a reprovação implica e para que essas mensagens se destinam!

A depreciação deixa muitas pessoas muito nervosas, e por um bom motivo. É isso que a depreciação deve fazer!

Ah, não há problema então. Meus cálculos finais são de cerca de US $ 30 milhões, mas acho que estava errado.

USD $ 30 milhões soa como uma estimativa muito baixa para mim, considerando quantos pacotes dependem deste projeto direta ou indiretamente!

Estou surpreso e surpreso com quantas pessoas aqui pensam que têm o direito ao software livre.

Estou surpreso e surpreso com quantas pessoas aqui pensam que têm o direito ao software livre.

Estou surpreso e surpreso com a quantidade de pessoas que pensam que não têm qualquer responsabilidade com respeito a como suas ações afetam seus usuários apenas porque seus produtos são gratuitos ou de código aberto.

IMO é uma questão de respeito básico tratar seus usuários / clientes da mesma forma, se eles estão pagando para usar seu aplicativo / biblioteca ou se não estão pagando.

Você iria descontinuar um projeto usado por milhões de outros projetos como uma dependência se as pessoas estivessem pagando por ele, a menos que você tivesse uma razão muito, muito, muito boa para isso (como projetos dependentes quebrando se as pessoas não realizassem algum tipo de ação em Tempo)?

@jslegers Exatamente meu ponto. Tão certo! Surpreendente!

@jslegers Exatamente meu ponto. Tão certo! Surpreendente!

Panela...

Chaleira...

Não consigo pensar em nada mais legítimo do que argumentar que os usuários de uma forma ou de outra "devem" a você por lhes dar software de código aberto e que eles deveriam se sentir "honrados" ou "gratos" a você e, portanto, não têm o direito de reclamar de qualquer espécie quando suas ações impactam seus projetos diretamente.

Claro, manter um projeto de código aberto por anos requer muito trabalho árduo e dedicação. Claro, é algo para ser admirado quando as pessoas estão dispostas a fazer isso em seu tempo livre, sem nenhuma compensação financeira. Mas isso ainda não é desculpa para agir com todo o direito e deixar seus usuários no frio quando eles mais precisam de você e há várias alternativas sem esforço!

@CliffS

Pessoalmente, aproveitei a oportunidade para atualizar gradualmente meus pacotes. O kraken-exchange, por exemplo, caiu de 5,9 MB para 284 KB instalados, mudando para bent.

Acabei de dar uma olhada e o package.json ainda está se referindo à versão de solicitação 2,88.0

Acabei de dar uma olhada e o package.json ainda está se referindo à versão de solicitação 2,88.0

@JonathanRowell Sim. No momento, está sendo testado antes de colocá-lo no npm. A versão v1.9.0 chegará no final do dia.

Mas isso ainda não é desculpa para agir com todo o direito e deixar seus usuários no frio quando eles mais precisam de você e há várias alternativas sem esforço!

Exatamente, é por isso que temos pessoas como @jslegers dispostos a dedicar algumas horas de seu tempo livre todos os dias para ajudar na manutenção, diminuindo a carga de trabalho e levando o projeto adiante, ao invés de reclamar de um problema!

Oh espere.

Exatamente, é por isso que temos pessoas como @jslegers dispostos a dedicar algumas horas de seu tempo livre todos os dias para ajudar na manutenção, diminuindo a carga de trabalho e levando o projeto adiante, ao invés de reclamar de um problema!

Errado!

É por isso que temos o pessoal amigável da equipe do Postman , que já tem seu próprio request fork denominado postman-request , que pode atuar como um substituto imediato para request e que é mantido ativamente! A alternativa de bom senso para descontinuar request seria pedir que eles assumissem a manutenção de request .

No caso de o pessoal do Postman recusar por qualquer motivo, request ainda poderia recomendar oficialmente postman-request como um substituto completo de recurso no aviso de suspensão de uso, para evitar que centenas de recursos sejam desnecessariamente desperdiçados - de não milhares - de desenvolvedores procurando independentemente por um substituto instantâneo.

Alternativamente, você pode simplesmente anunciar a suspensão oficial da manutenção / suporte de request e deixá-lo morrer lentamente e pacificamente sem um aviso de depreciação, uma vez que não há realmente necessidade de descontinuar OU continuar a manutenção de um pacote que funciona perfeitamente bem e não está não está prestes a quebrar em um futuro próximo.

Qualquer uma dessas três abordagens seria infinitamente melhor do que a abordagem atual e não exigiria quaisquer recursos adicionais de nenhuma parte.

Não acho que discutir se um ou outro está ou não vinculado a suas expectativas é construtivo nem ajudará a abordar as questões em questão. Todos nós recebemos, damos e cooperamos uns com os outros na esperança de que os próprios problemas possam ser resolvidos mais facilmente, mas ninguém pode forçar o outro a agir contra sua vontade.

Eu acredito que os fatos são que a) o atual proprietário não quer mais levar o projeto adiante (perfeitamente compreensível), mas também que b) muitas pessoas estão sentindo muita dor com o aviso de reprovação, pois a migração para longe dele não acontecer imediatamente na maioria das vezes (perfeitamente compreensível também).

Portanto, parece-me que um compromisso razoável seria, de forma semelhante ao que @jslegers sugere, que a propriedade do projeto seja transferida para alguém interessado e disposto a aceitá-lo, remover o aviso de

Então, @mikeal , você está disposto a entregar a propriedade do projeto para outra pessoa?

E mais alguém está disposto a aceitar isso do Mikeal para resolver o problema que as pessoas estão tendo com o aviso que está sendo emitido?

Além da cooperação para a entrega da propriedade do projeto, nenhum de nós pode falar pelos outros, dizendo-lhes para fazer isso ou aquilo; só se pode falar por si mesmo.

outro fato que não foi muito mencionado neste tópico é o impacto na segurança de transferir a propriedade de um pacote tão popular. Tivemos incidentes recentes em que a transferência de propriedade foi para um agente mal-intencionado e resultou em atividades maliciosas em novas versões do pacote. pacotes populares como esse são ótimos alvos para esse tipo de ator.

Não vou comentar sobre a confiabilidade de qualquer equipe específica que poderia assumir a propriedade, mas é importante reconhecer o quão arriscada essa sugestão realmente é. descontinuar este pacote não impede que os garfos continuem a mantê-lo com um nome diferente, mas a mudança de nome permite que um consumidor tome a decisão de consumir esse garfo, em vez de acontecer automaticamente, sem oportunidade de avaliar o risco para seu projeto.

outro fato que não foi muito mencionado neste tópico é o impacto na segurança de transferir a propriedade de um pacote tão popular. Tivemos incidentes recentes em que a transferência de propriedade foi para um agente mal-intencionado e resultou em atividades maliciosas em novas versões do pacote. pacotes populares como esse são ótimos alvos para esse tipo de ator.

Obviamente, você não pode simplesmente transferir a propriedade para qualquer pessoa. Mas a equipe do Postman parece uma escolha lógica, porque ...

  • Eles têm uma reputação a proteger e, portanto, não podem prejudicar o projeto request injetando código malicioso nele
  • Como uma plataforma para desenvolvimento e teste de API, pode ser uma vitória de marketing para eles se tornarem o mantenedor oficial de um pacote NPM muito popular usado por muitos de seus clientes em potencial
  • Como eles já mantêm seu próprio fork de request , não devem exigir recursos adicionais deles. Eles poderiam simplesmente mesclar seu fork em request e mover recursos de seu próprio fork (que não seriam mais necessários) para o repo oficial request

Obviamente, não há garantia de que eles aceitarão. Mas se eles tivessem algum bom senso, eles iriam pular sobre isso imediatamente. Portanto, a menos que um mantenedor de request já tenha tentado contatá-los e possa confirmar que eles de fato recusaram esta proposta, definitivamente vale a pena tentar, IMO!

não há realmente necessidade de descontinuar OU continuar a manutenção de um pacote que funciona perfeitamente bem e não está prestes a quebrar no futuro próximo.

Isso é tão atrasado que nem sei por onde começar. O fato de um pacote não ter manutenção e ser removido é o ponto de descontinuação.
O proprietário está informando que você está construindo uma dívida técnica ao usá-la para que possa seguir em frente. A melhor coisa sobre uma descontinuação oficial via npm é exatamente que as pessoas recebem uma indicação clara disso, em vez de ter que descobrir anos depois (em seu cenário "deixe-o morrer lentamente"), onde provavelmente já é tarde demais para considere uma migração suave.

Pacotes amplamente usados ​​e posteriormente abandonados não morrem pacificamente. Eles morrem quando as pessoas que os usam começam a se afastar em pânico, depois que seu estado sem manutenção realmente leva à quebra de materiais e à abertura de brechas de segurança.

Encare os fatos, nem você nem eu provavelmente saberíamos o estado da solicitação sem o aviso de suspensão de uso. Nem a grande maioria dos usuários.

Tentei instalar o angular no linux e depois no windows e em ambos não consegui, após executar o comando npm install -g @ angular / cli @ latest em ambos apareceu este erro

C: \ Usuários \ Hanzell> npm install -g @ angular / cli @ mais recente
npm WARN descontinuado [email protected]: o pedido foi descontinuado, consulte # 3142
C: \ Users \ Hanzell \ AppData \ Roamingnpm \ ng -> C: \ Users \ Hanzell \ AppData \ Roamingnpmnode_modules @ angular \ cli \ bin \ ng

@ angular / [email protected] postinstall C: \ Users \ Hanzell \ AppData \ Roamingnpmnode_modules @ angular \ cli
node ./bin/postinstall/script.js

Então, eu criei o repositório e este apareceu

C: \ Users \ Hanzell \ Desktop> ng new
? Que nome você gostaria de usar para o novo espaço de trabalho e projeto inicial? olá
? Você gostaria de adicionar o roteamento angular? Não
? Qual formato de folha de estilo você gostaria de usar? CSS
CRIAR hola / angular.json (3551 bytes)
CRIAR hola / package.json (1281 bytes)
CRIAR hola / README.md (1021 bytes)
CRIAR hola / tsconfig.json (543 bytes)
CREATE hola / tslint.json (1953 bytes)
CRIAR hola / .editorconfig (246 bytes)
CRIAR hola / .gitignore (631 bytes)
CRIAR hola / lista de navegadores (429 bytes)
CRIAR hola / karma.conf.js (1016 bytes)

npm ERR! Um registro completo desta execução pode ser encontrado em:
npm ERR! C: \ Users \ Hanzell \ AppData \ Roamingnpm-cache_logs \ 2020-03-01T05_15_55_441Z-debug.log
× Falha na instalação do pacote, veja acima.
O fluxo de trabalho esquemático falhou. Veja acima.
CRIAR hola / src / assets / .gitkeep (0 bytes

ajuda!

Verifique a atualização do npm e depois a instalação do npm no projeto angular

Isso é tão atrasado que nem sei por onde começar. O fato de um pacote não ter manutenção e ser removido é o ponto de descontinuação.

O fato de um pacote não ter manutenção e REQUER ser removido antes do término do período de carência é o ponto de descontinuação.

Se não houver nenhum requisito para se mudar antes de um ponto específico no tempo, você não deve descontinuar ... pelo menos não a menos que você possa propor uma substituição imediata (como postman-request neste caso)!

A diferença pode ser sutil, mas a consequência é significativa. Você está desperdiçando recursos de possivelmente muitos milhares de empresas sem um bom motivo, descontinuando o uso, o que poderia ser evitado apenas encerrando a manutenção e deixando por isso mesmo!

outro fato que não foi muito mencionado neste tópico é o impacto na segurança de transferir a propriedade de um pacote tão popular. Tivemos incidentes recentes em que a transferência de propriedade foi para um agente mal-intencionado e resultou em atividades maliciosas em novas versões do pacote. pacotes populares como esse são ótimos alvos para esse tipo de ator.

... a descontinuação deste pacote não impede que os forks continuem a manter este pacote com um nome diferente

É justo; Acho que podemos esperar um pouco para ter notícias do pessoal do Carteiro e avaliar se a transferência para eles é viável; mas por outro lado, os garfos parecem ser o caminho a seguir.

Não, você não está perdendo tempo de ninguém, deixando claro que uma de suas dependências foi abandonada e quase certamente uma fonte de dívida técnica. O oposto é verdadeiro, e toda a discussão sobre este assunto é prova disso - uma discussão que provavelmente não teria acontecido tão cedo sem a suspensão do uso.

Não, você não está perdendo tempo de ninguém, deixando claro que uma de suas dependências foi abandonada e quase certamente uma fonte de dívida técnica.

Só porque um projeto foi abandonado, não significa que deva ser substituído por qualquer outra coisa.

Especialmente para projetos que usam várias dependências, todas usando request como dependência, o ganho potencial de tentar substituir request por outra coisa nem chega perto do esforço necessário para conseguir isso !

uma discussão que provavelmente não teria acontecido tão cedo sem a suspensão de uso.

Esta discussão não teria sido necessária sem a suspensão de uso.

Sim, em algum momento, com ou sem uma suspensão de uso. Esse ponto é sempre melhor alcançado mais cedo do que anos depois, quando os efeitos de um pacote sem manutenção começam a ser sentidos.

De qualquer forma, desisto disso. Divirta-se.

“Tudo é mutável, tudo aparece e desaparece; não há paz feliz até que a pessoa passe além da agonia da vida e da morte. ”

- Gautama Buda

@mikeal Você é um homem

Antes de entrar em detalhes e raciocinar, irei direto ao ponto. A coisa mais valiosa que request pode fazer pelo ecossistema JavaScript é entrar no modo de manutenção e parar de considerar novos recursos ou versões principais.

Pedimos desculpas antecipadamente aos outros commiters em request que têm feito o possível para melhorá-lo, mas é o melhor.

2009

A primeira versão de request foi um dos primeiros módulos criados para o ecossistema Node.js. As primeiras versões foram gravadas em APIs anteriores à interface de retorno de chamada padrão, streams, node_modules e npm. Nos primeiros anos, request e Node.js evoluíram juntos, cada um aprendendo um com o outro. À medida que o Node.js melhorava e migrava as interfaces principais, o mesmo ocorria com a solicitação. À medida que a solicitação adotava mudanças na biblioteca e streams do HTTP principal, ela também informava melhorias como o evento pipe (que ativou o proxy de uma linha de request ) e uma das muitas reescritas do http principal (o um que eu tive que escrever).

npm

request foi um dos primeiros módulos adicionados ao registro npm. À medida que o npm crescia, também crescia a dependência de request . Mesmo agora, quando npm é usado muito mais para trabalho de front-end do que de back-end, request continua sendo um dos módulos mais dependentes no registro. No momento em que escrevo isto, módulos de 41K dependem de solicitação e é baixado 14 milhões de vezes por semana.

O lugar que request ocupa no ecossistema Node.js não é mais o de um inovador, mas de um titular. Se você pesquisar no Google como fazer algo com HTTP em Node.js, os exemplos provavelmente mostrarão request como o cliente e express como o servidor. Isso tem dois efeitos notavelmente ruins.

É muito mais difícil para novas bibliotecas realizar tarefas semelhantes obter adoção por causa da posição atual request detém sobre o ecossistema. Também é muito difícil alterar a solicitação de qualquer maneira significativa, pois a mudança não só pode não ser adotada pela maioria de seus dependentes, mas também a desalinhava com os milhares de postagens de blog e respostas de estouro de pilha que usam request .

JavaScript moderno

Os últimos anos foram dramáticos em JavaScript. Recursos sobre os quais as pessoas falaram por anos foram de ideias a padrões e a recursos dos quais você pode confiar com segurança na maioria dos ambientes. A velocidade com que eles foram adotados é impressionante, principalmente graças à atualização automática dos navegadores e a um cronograma de lançamento agressivo do Node.js.

Os padrões básicos de request estão desatualizados. Algumas pessoas podem argumentar contra essa avaliação, e eu sei quem elas são, então não ficarei surpreso, mas é verdade. Muitas vezes tenho sido cético quanto ao impacto que alguns desses recursos teriam apenas para me pegar adotando-os no atacado não muito tempo depois de estarem disponíveis apenas na versão mais recente do Node.js.

Há uma transição acontecendo agora no ecossistema para esses padrões. Como isso será bagunçado ainda está no ar e não vou tentar ler as folhas de chá e descobrir como será o futuro a esse respeito. A pergunta para request é “Tentamos sobreviver a essa transição?” Há um ano, achei que a resposta era óbvia e que sim, mas agora estou convencido do contrário.

Uma versão de request escrita para realmente abraçar esses novos padrões de linguagem é, efetivamente, um novo módulo. Já explorei este espaço um pouco e tenho um projeto com o qual estou bastante feliz, mas é incompatível com request de todas as maneiras imagináveis. Qual é o valor em uma versão de request que é incompatível com os padrões antigos, mas não abrange totalmente os novos? De que adianta ser parcialmente compatível quando existe um mundo inteiro de novos módulos, escritos por novos desenvolvedores, que estão repensando esses problemas com esses padrões em mente?

A melhor coisa para esses novos módulos é que request desapareça lentamente, tornando-se apenas mais uma memória daquela pilha legada. Assumir a posição que request tem agora e aproveitá-la para uma parcela maior da próxima geração de desenvolvedores seria um desserviço para esses desenvolvedores, pois os afastaria de módulos melhores que não têm o fardo de request História de

Modo de manutenção

Aqui está o plano.

  • request deixará de aceitar novos recursos.
  • request deixará de considerar as alterações importantes.
  • Os committers que ainda estão ativos tentarão mesclar as correções em tempo hábil, mas sem promessas.
  • As liberações serão totalmente automatizadas, qualquer mesclagem no master será publicada. Já construí isso para alguns outros projetos usando GitHub Actions .

    • Teremos que remover colaboradores inativos e aplicar 2fa, porque os direitos de commit se tornarão efetivamente direitos de publicação npm.

O que acontecerá se nós apenas o deletarmos? essas dependências são um assassino!

@grikard Eu concordo com isso - boa análise. Mas sem querer soar trivial - esta é uma pergunta genuína - os americanos soletram o plural de "folha" como folhas? Eu lernt "folhas".

folhas é plural para folha :)

Instalando pacotes ... npm WARN deprecated [email protected] : a solicitação foi descontinuada, consulte https://github.com/request/request/issues/3142
se mais alguém vier aqui porque você tem um erro sobre
ng new my-app
tente novamente
sudo ng new my-app
feliz hackeando

Oi Como resolver esse erro? # 3142

Que erro?

https://github.com/request/request/issues/3142

Na quarta-feira, 11 de março de 2020, 20:23 Cliff Stanford [email protected]
escreveu:

Oi Como resolver esse erro? # 3142
https://github.com/request/request/issues/3142

Que erro?

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/request/request/issues/3142#issuecomment-597602350 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AN6OSLTSIY5LZVUEOX3JWHDRG57FNANCNFSM4HCP6LRA
.

Não posso concluir meu projeto por causa disso ... e é devido hoje à noite. Alguém pode ajudar a corrigir esse problema no pedido ??

@AELDREI Este não é um erro. A suspensão de uso é apenas um aviso / informação, tudo ainda funciona.
@ valentina-js "Isso" é apenas um aviso / informação, então não pode ser a causa de você não conseguir terminar seu projeto. Se você tem um problema, deve ter outra causa. Tente procurar uma mensagem de erro real e veja se há um problema semelhante relatado. Se não, abra um e descreva seu erro em detalhes.

Oh não. Isso não foi necessário. Rasgar

New Merch

Screenshot_2020-03-12_16-58-39

3sei8v

npm WARN deprecated [email protected] : a solicitação foi descontinuada, consulte https://github.com/request/request/issues/3142

Por favor, resolva isso! Não sei o que estou fazendo de errado:

npm WARN deprecated [email protected] : a solicitação foi descontinuada, consulte https://github.com/request/request/issues/3142
npm WARN checkPermissions Falta de acesso de gravação a / usr / local / lib / node_modules
npm ERR! código EACCES
npm ERR! acesso syscall
npm ERR! caminho / usr / local / lib / node_modules
npm ERR! errno -13
npm ERR! Erro: EACCES: permissão negada, acesso '/ usr / local / lib / node_modules'
npm ERR! [Erro: EACCES: permissão negada, acesso '/ usr / local / lib / node_modules'] {
npm ERR! pilha: "Erro: EACCES: permissão negada, acesso '/ usr / local / lib / node_modules'",
npm ERR! errno: -13,
npm ERR! código: 'EACCES',
npm ERR! syscall: 'acesso',
npm ERR! caminho: '/ usr / local / lib / node_modules'
npm ERR! }
npm ERR!
npm ERR! A operação foi rejeitada pelo seu sistema operacional.
npm ERR! É provável que você não tenha permissão para acessar este arquivo como o usuário atual
npm ERR!
npm ERR! Se você acredita que isso pode ser um problema de permissão, verifique novamente o
npm ERR! permissões do arquivo e seus diretórios ou tente executar
npm ERR! o comando novamente como root / administrador.

npm ERR! Um registro completo desta execução pode ser encontrado em:
npm ERR! /Users/Hazem/.npm/_logs/2020-03-15T16_16_03_301Z-debug.log

@hazembergg NPM não tem acesso de gravação a node_modules. Não há nada de errado com request que bloqueie npm install . Tente executá-lo com sudo .

Obrigado pela sua resposta rápida, funcionou como um encanto!

Então eu acho que estou ficando louco! Devo ter lido README pelo menos 20 vezes. Todo este programa está acima do meu conhecimento básico de HTML ...

_Como obtenho comentários do youtube? _
Devo executar o youtube-comment-scraper no nó? terminal básico? ou comando?
a resposta do nó é ...
a resposta do terminal é que o título muda, mas nada acontece

_E se eu quiser um arquivo csv? _
é o comando: youtube-comment-scraper --outputFile youtubecomments.csv --stdout --format csv correto?

_Ballpark quanto tempo demoraria para executar o programa e obter, digamos, mil comentários? _

@hazembergg Both. Consulte https://www.npmjs.com/package/youtube-comment-scraper#usage para uso da linha de comando e https://www.npmjs.com/package/youtube-comment-scraper#method para uso programático. Você também pode executar npx youtube-comment-scraper com Node.js instalado na linha de comando para acessar a CLI.

@Richienb Obrigado novamente pela informação! Vou estudá-los e espero ter sucesso!

Sim, parece que todo mundo está fazendo algo errado. Disseram-me que haveria custo zero para a decisão de descontinuar request .

Nunca há custo zero!

Estou enfrentando problemas com a criação do túnel de molho.
Usando o seguinte serviço de molho.
npm install -g wdio-sauce-service
25hnpm WARN deprecated [email protected] : a solicitação foi descontinuada, consulte https://github.com/request/request/issues/3142
25h

[email protected] postinstall / usr / local / lib / node_modules / wdio-sauce-service / node_modules / sauce-connect-launcher
scripts de nó / install.js || scripts nodejs / install.js

+ [email protected]

Obtendo o erro abaixo ao tentar criar o túnel de molho.
Não foi possível iniciar o Sauce Connect. Sinal do código de saída 1: nulo
Um serviço falhou no gancho 'onPrepare'
Erro: não foi possível iniciar o Sauce Connect. Sinal do código de saída 1: nulo
em ChildProcess.(/usr/local/lib/node_modules/wdio-sauce-service/node_modules/sauce-connect-launcher/lib/sauce-connect-launcher.js:566:12)
em ChildProcess.emit (events.js: 198: 13)
em ChildProcess.EventEmitter.emit (domain.js: 448: 20)
em Process.ChildProcess._handle.onexit (internal / child_process.js: 248: 12)

Por favor, seja respeitoso e evite postar perguntas sérias. Apenas memes sobre request .

@ anton-bot, deixe ir e siga em frente com sua vida.

Por favor, seja respeitoso e evite postar perguntas sérias. Apenas memes sobre request .

@ anton-bot, deixe ir e siga em frente com sua vida.

Let it go

Voltando à seriedade, agora que request foi "oficialmente" descontinuado por meio de npm deprecate , agora _cada_ usuário upstream está recebendo novos avisos sobre isso.

Podemos considerar isso por um momento? Acho que isso causou pânico indevido. Não apenas isso, mas os sistemas automatizados que confirmam seus logs agora estão fazendo referência a esse problema b / c da chave do problema no aviso de descontinuação.

Estou de acordo que request amadureceu ao ponto da obsolescência, mas se ainda funcionar bem e tiver centenas de dependências com vários níveis de manutenção, talvez não deva ser oficialmente descontinuado no npm, mas sim um big ol 'aviso em fonte máxima no README?

E então um dia cada um desses usuários dirá: "Por que não fomos avisados ​​sobre isso !?" 😄

mas se ainda funcionar bem e tiver centenas de dependências com vários níveis de manutenção, talvez não deva ser oficialmente descontinuado no npm, mas sim um grande e velho aviso em fonte máxima no README?

O problema é que essencialmente _nenhum_ os lê. 99% das pessoas que estão em pânico agora nunca saberiam que o pedido foi descontinuado, a menos que o NPM os avisasse sobre isso. _Nobody_ senta e vasculha o README de _todas_ suas dependências para descobrir quais não são mais mantidas - até que seja tarde demais.

Estou me repetindo, mas o cenário que você está propondo essencialmente significa que as pessoas descobrirão da maneira mais difícil que a solicitação foi descontinuada - quando ela eventualmente começa a quebrar coisas e causar brechas de segurança por ser uma instalação antiga e sem manutenção em um ambiente moderno. Quando isso acontecer, as pessoas precisarão _scramble_ por uma alternativa, em vez de ter a chance - como é agora - de procurar por uma enquanto a solicitação ainda está estável e utilizável, o que provavelmente leva mais um ano, pelo menos.

A solicitação de descontinuação foi a coisa responsável a fazer e não vai ser revertida. A comunidade deve concentrar seus esforços em chegar a um acordo sobre uma boa alternativa e / ou bifurcação, em vez de tentar derrubá-la. Ir em frente.

WARN obsoleto [email protected] : o pedido foi descontinuado, consulte https://github.com/request/request/issues/3142 .
Como posso corrigir esse erro?

@mrmehi Você pode ler a primeira mensagem aqui?

Não é um erro. Ou você depende diretamente da solicitação (e então você deve mover para outra biblioteca, por exemplo, got ou bent ), ou você depende transitivamente dela por meio de uma de suas dependências - então atualize-a se eles já mudou, ou faça um ping para seguir em frente.

@kibertoad Estou realmente confuso, o que devo fazer agora?
acontece quando tento baixar o expo.io

@kibertoad Estou realmente confuso, o que devo fazer agora?
acontece quando tento baixar o expo.io

Você não precisa fazer nada. Não é um erro, é um aviso. Isso é o que indica a parte "WARN" do log.
Você _pode_ avisar a expo.io que eles podem querer começar a procurar alternativas para request , porque ela está obsoleta e, portanto, pode algum dia parar de funcionar corretamente.
Mas eles parecem já estar cientes disso, como você pode ver aqui:
https://github.com/expo/expo-cli/issues/1659

A Microsoft ainda conta com este pacote. appcenter-cli fornece este aviso de suspensão de uso na instalação:

npm WARN deprecated [email protected] : a solicitação foi descontinuada, consulte https://github.com/request/request/issues/3142

Dado o histórico da equipe do AppCenter, parece improvável que isso mude tão cedo. Nossos logs de construção estão cheios de avisos sobre pacotes que foram descontinuados há mais de um ano em alguns casos.

Por favor, alguém pode me ajudar Estou enfrentando dificuldades ao instalar o expo-cli --global.
Eu instalei o node, git. eu escrevo o comando como npm install expo-cli --global, mas enfrento o problema como:
"npm WARN deprecated [email protected] : a solicitação foi descontinuada, consulte https://github.com/request/request/issues/3142
[..................] | fetchMetadata: WARN deprecated [email protected] : a solicitação foi descontinuada, consulte https://github.com/request/request/issues/3142 "".
o que estou recebendo esse erro. gentilmente me responda como resolver esse problema.

@mrmehi Você pode ler a primeira mensagem aqui?

Não é um erro. Ou você depende diretamente da solicitação (e então você deve mover para outra biblioteca, por exemplo, got ou bent ), ou você depende transitivamente dela por meio de uma de suas dependências - então atualize-a se eles já mudou, ou faça um ping para seguir em frente.

por favor você pode me ajudar a resolver este problema? estou enfrentando o problema.

@lemessur Acontece que os mantenedores simplesmente não sabiam que a solicitação estava obsoleta. Consulte https://github.com/microsoft/appcenter-cli/pull/758#issuecomment -603667106

Alguém, por favor, coloque isso no início do comentário do problema principal:

Aviso de suspensão de uso

Se você está recebendo WARN deprecated [email protected]: request has been deprecated, see #3142 ao tentar instalar suas dependências, certifique-se de que isso NÃO é um erro. O autor do pacote que você está instalando (ou você, se depender de request ) precisa migrar para outra biblioteca. Veja: https://github.com/request/request/issues/3143

@Richienb
Veja # 3142 (comentário)

Então, o que devo fazer agora. por favor você pode me ajudar a resolver este problema?

@Richienb
Veja # 3142 (comentário)

Sou novo no github e não conseguia entender o que fazer. você pode me dizer passo a passo como posso resolver meu problema? procurando sua resposta rápida.

@alijatoi expo-cli está usando request portanto, sua dependência deve ser alterada.

@Richienb Então o que devo fazer agora? devo esperar ou existe alguma outra maneira de instalar o Expo-CLI.
por favor me ajude eu estou esperando.
obrigada

@alijatoi Crie um problema e / ou aguarde.

@Richienb obrigado pela sua resposta.
não há outra maneira de instalar o expo cli?

@alijatoi não

pessoal, se você está enfrentando problemas, instale expo-cli com npm por causa da mensagem obsoleta: instale o yarn e depois instale o expo-cli

@caio-vinicius Isso só funciona porque o yarn exibe o aviso apenas uma vez e continuará a exibi-lo ao regenerar o arquivo de bloqueio.

pessoal, se você está enfrentando problemas, instale expo-cli com npm por causa da mensagem obsoleta: instale o yarn e depois instale o expo-cli

@ caio-vinicius sim, eu fiz a instalação usando install yarn then yarn install expo-cli globalmente, mas depois de instalar quando eu verifico a versão do expo cli, dá o problema de que expo não define nenhum comando interno ou externo

@alijatoi , certifique-se de usar a sintaxe correta ao usar o yarn para instalar globalmente.

https://classic.yarnpkg.com/en/docs/cli/global/

No entanto, @alijatoi , uma instalação interrompida por um aviso de depreciação é quase certamente um problema com seu ambiente ou com o pacote que você está tentando instalar. Não é específico para solicitar e nada que você deva relatar aqui.

Estou um pouco atrasado para a festa, mas seria bom adicionar uma pequena lista de alternativas para que as pessoas possam usá-las para substituir o request , como nodejs construídos em http.ClientRequest . Obrigado.

F

Eu concordo com tudo que você disse sobre forma, compatibilidade e progresso, mas
Não consigo ver por que [email protected] não pode fazer isso com alterações significativas. Afinal - essa é a ideia por trás de semver ...

Muitas outras bibliotecas adotaram os novos padrões e recursos e, portanto, quebraram a compatibilidade e aumentaram seus principais.

Mesmo que seja um módulo completamente novo - o nome representa a credibilidade e
experiência de lições aprendidas, que fico triste em ver ir embora.

Interessado em aprender mais sobre isso.

Bem, obrigado pela carona e todo o trabalho duro que você fez. 👍

Você, meu senhor, é um herói.

Eu entendo a razão por trás disso, é fazer JS / Node (em geral), progredir um pouco mais rápido.

Você fez "quase" tanto para o espaço NodeJS quanto jQuery fez para o espaço do navegador / DOM. É um prazer trabalhar com TCP, e isso é fundamental para o desenvolvimento de back-end.

Eu te agradeço por isso.

Tome cuidado.

Então, qual é o guia sobre a maneira alternativa de fazer solicitações de https para mim que é novo no desenvolvimento de back-end com node?

Obrigado, Cliff. Vou dar uma olhada.

npm advirta aviso Registro inesperado para https://registry.npmjs.org/ : EINTEGRITY Aviso Diversos: sha512-7G3s83fOoweLlAsvR3wtw4DnepkrY + / FxmYxk1XnfAjE9xnoWRy9cLHWCywcc6l6018X1RdNxpJdtqX9WQAEXw == integridade da consistência falhou ao usar sha512: queria sha512-7G3s83fOoweLlAsvR3wtw4DnepkrY + / FxmYxk1XnfAjE9xnoWRy9cLHWCywcc6l6018X1RdNxpJdtqX9WQAEXw == mas tem sha512-NhZAWqNqTzZaAfgJYp0NlbBDUX8BMyOmobe3kYnymXfSxDgaiej4nP6N3aLVDtBTPHOfivySRs + AVsca0JgrTQ ==. (2.0905 bytes)
Registro npm WARN Usando dados desatualizados de https://registry.npmjs.org/ devido a um erro de solicitação durante a revalidação.
npm WARN deprecated [email protected] : a solicitação foi descontinuada, consulte https://github.com/request/request/issues/3142
npm ERR! código EINTEGRITY
npm ERR! errno EINTEGRIDADE
npm ERR! Corpo resposta inválida ao tentar buscar https://registry.npmjs.org/uuid : verificação de integridade falhou por sha512-7G3s83fOoweLlAsvR3wtw4DnepkrY + / FxmYxk1XnfAjE9xnoWRy9cLHWCywcc6l6018X1RdNxpJdtqX9WQAEXw == (C: \ Users \ Mulamba SERGIO \ AppData \ Roamingnpm-cache_cacache \ content-v2 \ sha512 \ ec \ 6d \ ecf377cea3078b940b2f477c2dc380e77a992b63efc5c666319355e77c08c4f719e8591cbd70b1d60b2c1c73a97ad35f17d5174dc6925db6a5fd5900045f)

npm ERR! Um registro completo desta execução pode ser encontrado em:
npm ERR! C: \ Users \ MULAMBA SERGIO \ AppData \ Roamingnpm-cache_logs \ 2020-04-03T22_54_57_842Z-debug.log

npm WARN deprecated [email protected]: a solicitação foi descontinuada, consulte https://github.com/request/request/issues/3142
npm WARN depreciado [email protected]: Esta versão foi descontinuada de acordo com a política de suporte do hapi (hapi.im/support). Atualize para a versão mais recente para obter os melhores recursos, correções de bugs e patches de segurança. Se você não puder atualizar neste momento, o suporte pago está disponível para versões mais antigas (hapi.im/commercial).
npm WARN deprecated [email protected]: a solicitação foi descontinuada, consulte https://github.com/request/request/issues/3142
npm WARN obsoleto [email protected]: core-js @ <3 não é mais mantido e não é recomendado para uso devido ao número de problemas. Por favor, atualize suas dependências para a versão atual do core-js @ 3.
npm WARN depreciado [email protected]: Esta versão foi descontinuada de acordo com a política de suporte hapi (hapi.im/support). Atualize para a versão mais recente para obter os melhores recursos, correções de bugs e patches de segurança. Se você não puder atualizar neste momento, o suporte pago está disponível para versões mais antigas (hapi.im/commercial).
npm WARN depreciado [email protected]: Esta versão foi descontinuada de acordo com a política de suporte hapi (hapi.im/support). Atualize para a versão mais recente para obter os melhores recursos, correções de bugs e patches de segurança. Se você não puder atualizar neste momento, o suporte pago está disponível para versões mais antigas (hapi.im/commercial).
npm WARN deprecated [email protected]: Esta versão foi descontinuada de acordo com a política de suporte do hapi (hapi.im/support). Atualize para a versão mais recente para obter os melhores recursos, correções de bugs e patches de segurança. Se você não puder atualizar neste momento, o suporte pago está disponível para versões mais antigas (hapi.im/commercial).
npm WARN obsoleto [email protected]: Este módulo foi movido e agora está disponível em @ hapi / topo. Atualize suas dependências, pois esta versão não é mais mantida e pode conter bugs e problemas de segurança.
npm WARN obsoleto [email protected]: Este módulo foi movido e agora está disponível em @ hapi / hoek. Atualize suas dependências, pois esta versão não é mais mantida e pode conter bugs e problemas de segurança.
C: \ Usuários \ Matheus \ AppData \ Roaming \ npm \ expo -> C: \ Usuários \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ bin \ expo.js
C: \ Usuários \ Matheus \ AppData \ Roaming \ npm \ expo-cli -> C: \ Usuários \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ bin \ expo.js
npm AVISO opcional PULAR DEPENDÊNCIA OPCIONAL: @ expo / travelling-fastlane-darwin @ 1.13.1 (node_modules \ expo-cli \ node_modules \ @expo \ travelling-fastlane-darwin):
npm AVISO notsup PULAR DEPENDÊNCIA OPCIONAL: plataforma não suportada para @ expo / travelling-fastlane-darwin @ 1.13.1: queria {"os": "darwin", "arch": "any"} (atual: {"os": " win32 "," arch ":" x64 "})
npm WARN opcional PULANDO DEPENDÊNCIA OPCIONAL: @ expo / ngrok-bin-linux-arm @ 2.2.8 (node_modules \ expo-cli \ node_modules \ @expo \ ngrok-bin \ node_modules \ @expo \ ngrok-bin-linux-arm) :
npm AVISO notsup PULAR DEPENDÊNCIA OPCIONAL: plataforma não suportada para @ expo / ngrok-bin-linux-arm @ 2.2.8: queria {"os": "linux", "arch": "arm"} (atual: {"os" : "win32", "arch": "x64"})
npm WARN opcional PULANDO DEPENDÊNCIA OPCIONAL: @ expo / ngrok-bin-darwin-ia32 @ 2.2.8 (node_modules \ expo-cli \ node_modules \ @expo \ ngrok-bin \ node_modules \ @expo \ ngrok-bin-darwin-ia32) :
npm AVISO notsup PULAR DEPENDÊNCIA OPCIONAL: plataforma sem suporte para @ expo / ngrok-bin-darwin-ia32 @ 2.2.8: queria {"os": "darwin", "arch": "ia32"} (atual: {"os" : "win32", "arch": "x64"})
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: @ expo / ngrok-bin-freebsd-x64 @ 2.2.8 (node_modules \ expo-cli \ node_modules \ @expo \ ngrok-bin \ node_modules \ @expo \ ngrok-bin-freebsd-x64) :
npm AVISO notsup PULAR DEPENDÊNCIA OPCIONAL: plataforma não suportada para @ expo / ngrok-bin-freebsd-x64 @ 2.2.8: queria {"os": "freebsd", "arch": "x64"} (atual: {"os" : "win32", "arch": "x64"})
npm WARN opcional PULANDO DEPENDÊNCIA OPCIONAL: @ expo / ngrok-bin-freebsd-ia32 @ 2.2.8 (node_modules \ expo-cli \ node_modules \ @expo \ ngrok-bin \ node_modules \ @expo \ ngrok-bin-freebsd-ia32) :
npm AVISO notsup IGNORANDO DEPENDÊNCIA OPCIONAL: plataforma sem suporte para @ expo / ngrok-bin-freebsd-ia32 @ 2.2.8: queria {"os": "freebsd", "arch": "ia32"} (atual: {"os" : "win32", "arch": "x64"})
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: @ expo / ngrok-bin-linux-ia32 @ 2.2.8 (node_modules \ expo-cli \ node_modules \ @expo \ ngrok-bin \ node_modules \ @expo \ ngrok-bin-linux-ia32) :
npm AVISO notsup PULAR DEPENDÊNCIA OPCIONAL: plataforma não suportada para @ expo / ngrok-bin-linux-ia32 @ 2.2.8: queria {"os": "linux", "arch": "ia32"} (atual: {"os" : "win32", "arch": "x64"})
npm WARN opcional PULANDO DEPENDÊNCIA OPCIONAL: @ expo / ngrok-bin-linux-x64 @ 2.2.8 (node_modules \ expo-cli \ node_modules \ @expo \ ngrok-bin \ node_modules \ @expo \ ngrok-bin-linux-x64) :
npm AVISO notsup PULAR DEPENDÊNCIA OPCIONAL: plataforma não suportada para @ expo / ngrok-bin-linux-x64 @ 2.2.8: queria {"os": "linux", "arch": "x64"} (atual: {"os" : "win32", "arch": "x64"})
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: @ expo / ngrok-bin-darwin-x64 @ 2.2.8 (node_modules \ expo-cli \ node_modules \ @expo \ ngrok-bin \ node_modules \ @expo \ ngrok-bin-darwin-x64) :
npm AVISO notsup PULAR DEPENDÊNCIA OPCIONAL: plataforma não suportada para @ expo / ngrok-bin-darwin-x64 @ 2.2.8: queria {"os": "darwin", "arch": "x64"} (atual: {"os" : "win32", "arch": "x64"})
npm WARN opcional PULANDO DEPENDÊNCIA OPCIONAL: @ expo / ngrok-bin-win32-ia32 @ 2.2.8-beta.1 (node_modules \ expo-cli \ node_modules \ @expo \ ngrok-bin \ node_modules \ @expo \ ngrok-bin- win32-ia32):
npm AVISO notsup IGNORANDO DEPENDÊNCIA OPCIONAL: plataforma não suportada para @ expo / ngrok-bin-win32-ia32 @ 2.2.8-beta.1: queria {"os": "win32", "arch": "ia32"} (atual: {"os": "win32", "arch": "x64"})
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: @ expo / ngrok-bin-sunos-x64 @ 2.2.8 (node_modules \ expo-cli \ node_modules \ @expo \ ngrok-bin \ node_modules \ @expo \ ngrok-bin-sunos-x64) :
npm AVISO notsup PULAR DEPENDÊNCIA OPCIONAL: plataforma não suportada para @ expo / ngrok-bin-sunos-x64 @ 2.2.8: queria {"os": "sunos", "arch": "x64"} (atual: {"os" : "win32", "arch": "x64"})
npm WARN opcional PULANDO DEPENDÊNCIA OPCIONAL: @ expo / ngrok-bin-linux-arm64 @ 2.2.8 (node_modules \ expo-cli \ node_modules \ @expo \ ngrok-bin \ node_modules \ @expo \ ngrok-bin-linux-arm64) :
npm AVISO notsup PULAR DEPENDÊNCIA OPCIONAL: plataforma não suportada para @ expo / ngrok-bin-linux-arm64 @ 2.2.8: queria {"os": "linux", "arch": "arm64"} (atual: {"os" : "win32", "arch": "x64"})
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: fsevents@^1.2.7 (node_modules \ expo-cli \ node_modules \ chokidar \ node_modules \ fsevents):
npm AVISO notsup IGNORANDO DEPENDÊNCIA OPCIONAL: Plataforma não suportada para [email protected]: queria {"os": "darwin", "arch": "any"} (atual: {"os": "win32", "arch": "x64"})
npm WARN @ expo / image-utils @ 0.2.17 requer um par de sharp-cli@^1.10.0 mas nenhum está instalado. Você deve instalar dependências de mesmo nível.
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ abbrev):
npm AVISO enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ abbrev' -> 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.abbrev.DELETE '
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ ansi-regex):
npm WARN enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ ansi-regex' -> 'C : \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.ansi-regex.DELETE '
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ aproba):
npm AVISO enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ aproba' -> 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.aproba.DELETE '
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ balanced-match):
npm AVISO enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ balanced-match' -> 'C : \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.balanced-match.DELETE '
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ chownr):
npm WARN enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ chownr' -> 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.chownr.DELETE '
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ code-point-at):
npm AVISO enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ code-point-at' -> 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.code-point-at.DELETE'
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ concat-map):
npm WARN enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ concat-map' -> 'C : \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.concat-map.DELETE '
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ console-control-strings):
npm WARN enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ console-control-strings' -> 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.console-control-strings.DELETE'
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ core-util-is):
npm WARN enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ core-util-is' -> 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.core-util-is.DELETE'
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ deep-extend):
npm WARN enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ deep-extend' -> 'C : \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.deep-extend.DELETE '
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ delegates):
npm AVISO enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ delegates' -> 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.delegates.DELETE '
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ detect-libc):
npm WARN enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ detect-libc' -> 'C : \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.detect-libc.DELETE '
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ fs.realpath):
npm AVISO enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Usuários \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ fs.realpath' -> 'C : \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.fs.realpath.DELETE '
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ has-unicode):
npm AVISO enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ has-unicode' -> 'C : \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.has-unicode.DELETE '
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ inherits):
npm AVISO enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ inherits' -> 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.inherits.DELETE '
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ ini):
npm AVISO enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ ini' -> 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.ini.DELETE '
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ isarray):
npm AVISO enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ isarray' -> 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.isarray.DELETE '
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ minimist):
npm AVISO enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ minimist' -> 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.minimist.DELETE '
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ ms):
npm WARN enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ ms' -> 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.ms.DELETE '
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ npm-normalize-package-bin):
npm AVISO enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ npm-normalize-package-bin' -> 'C: \ Usuários \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.npm-normalize-package-bin.DELETE'
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ number-is-nan):
npm WARN enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ number-is-nan' -> 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.number-is-nan.DELETE'
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ object-assign):
npm WARN enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ object-assign' -> 'C : \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.object-assign.DELETE '
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ os-homedir):
npm AVISO enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ os-homedir' -> 'C : \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.os-homedir.DELETE '
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ os-tmpdir):
npm WARN enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ os-tmpdir' -> 'C : \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.os-tmpdir.DELETE '
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ path-is-absoluto):
npm WARN enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ path-is-absoluto' -> 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.path-is-absolute.DELETE'
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ process-nextick-args):
npm WARN enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ process-nextick-args' -> 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.process-nextick-args.DELETE'
npm WARN opcional SKIPPING DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ safe-buffer):
npm WARN enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ safe-buffer' -> 'C : \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.safe-buffer.DELETE '
npm WARN opcional SKIPPING DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ safer-buffer):
npm WARN enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ safer-buffer' -> 'C : \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.safer-buffer.DELETE '
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ sax):
npm AVISO enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ sax' -> 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.sax.DELETE '
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ semver):
npm AVISO enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ semver' -> 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.semver.DELETE '
npm WARN opcional SKIPPING DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ set-blocking):
npm WARN enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ set-blocking' -> 'C : \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.set-blocking.DELETE '
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ signal-exit):
npm WARN enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ signal-exit' -> 'C : \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.signal-exit.DELETE '
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ strip-json-comments):
npm WARN enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ strip-json-comments' -> 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.strip-json-comments.DELETE'
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ util-deprecate):
npm AVISO enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ node-deprecate' -> util 'C : \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.util-deprecate.DELETE '
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ wrappy):
npm AVISO enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ wrappy' -> 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.wrappy.DELETE '
npm WARN opcional IGNORANDO DEPENDÊNCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ yallist):
npm AVISO enoent SKIPPING DEPENDÊNCIA OPCIONAL: ENOENT: nenhum arquivo ou diretório, renomear 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ yallist' -> 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.yallist.DELETE '

npm WARN deprecated [email protected] : a solicitação foi descontinuada, consulte https://github.com/request/request/issues/3142
por favor você pode me ajudar? Não consigo resolver este problema e não consigo iniciar o meu projeto

npm WARN descontinuado [email protected] : o pedido foi descontinuado, consulte # 3142
por favor você pode me ajudar? Não consigo resolver este problema e não consigo iniciar o meu projeto

Eu também não

@ liaz98 @TheLitz não é um erro, é um aviso. Se seu projeto não for compilado / iniciado devido a um aviso do npm, algo está errado com seu projeto e / ou ambiente. Este não é um problema com o pedido.

@ liaz98 @TheLitz não é um erro, é um aviso. Se seu projeto não for compilado / iniciado devido a um aviso do npm, algo está errado com seu projeto e / ou ambiente. Este não é um problema com o pedido.

mas quando tento fazer a Expo não funciona

@TheLitz então isso é um problema com a Expo, e você deve relatá-lo em seu bug tracker. Não é nada que possa ou seja resolvido do lado da solicitação.

@TheLitz então isso é um problema com a Expo, e você deve relatá-lo em seu bug tracker. Não é nada que possa ou seja resolvido do lado da solicitação.

OK. Obrigado

solicitamos um pedido futuro.

tldr;
o que devo usar agora?

@YashKumarVerma use postman-request

@TheLitz então isso é um problema com a Expo, e você deve relatá-lo em seu bug tracker. Não é nada que possa ou seja resolvido do lado da solicitação.

você está resolvendo esse problema ????
npm WARN descontinuado [email protected] : o pedido foi descontinuado,

Então, qual é o guia sobre a maneira alternativa de fazer solicitações de https para mim que é novo no desenvolvimento de back-end com node?

@OluwafemiAdesegha
Você conseguiu obter alguma clareza sobre para onde ir? Eu estou no mesmo barco que você! :(

Para quem procura alternativas, consulte # 3143 ( @ farhan3040 @OluwafemiAdesegha @iamdesfranco )

@mikeal, eu recomendo encerrar este problema;)

@iamdesfranco @ farhan3040 HTTP foi descontinuado, use Gopher ou UDP

@mikeal, eu recomendo encerrar este problema;)

Ou melhor, tranque-o. Essencialmente, tudo o que precisa ser dito foi dito neste ponto, e as únicas perguntas feitas tendem a ser aquelas que já foram respondidas (várias vezes).

Franco,

Desculpas pela resposta tardia. Ainda estou tentando ver o que eu faria
finalmente vá com base nas sugestões dadas.

Na segunda-feira, 6 de abril de 2020, 9h12, Franco Labuschagne [email protected]
escreveu:

Qual é o guia sobre a maneira alternativa de fazer solicitações de https para mim
o que é novo no desenvolvimento de back-end com node?

Você conseguiu obter alguma clareza sobre para onde ir? Estou no mesmo barco
como você! :(

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/request/request/issues/3142#issuecomment-609643295 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AOL4QYXM7V2BUK5LZCS7LDDRLGFH5ANCNFSM4HCP6LRA
.

e as alternativas possíveis referem-se a este problema.

Onde encontrei as alternativas nesta página?

É a sugestão de usar fetch no navegador + fetch lib para o node, ou apenas uma alternativa baseada em promessa, etc?

@TomYeoman A sugestão é não usar request .

@Richienb obrigado. Acho que é importante ter um link para isso no README.

Eu removi a pasta "node_modules" e o arquivo "package-lock.json" e, em seguida, executei os 2 comandos a seguir.
npm init
npm install

E então, funcionou corretamente.

Os committers que ainda estão ativos tentarão mesclar as correções em tempo hábil, mas sem promessas.

Brilhante trocadilho acidental (?)

npm WARN deprecated [email protected] : a solicitação foi descontinuada, consulte https://github.com/request/request/issues/3142

como resolver isso ??,

@ anton-bot Nenhum malware, por favor.

npm WARN descontinuado [email protected] : o pedido foi descontinuado, consulte # 3142

como resolver isso ??,

@Amouthinie não há nada para resolver, não é um erro. O NPM está avisando que request está obsoleto e você (ou quem quer que mantenha suas dependências que por sua vez dependem de request ) deve considerar a mudança para um pacote mantido ativamente.

Tenho tido dois problemas:
1 - sudo apt-get install nodejs npm
Lendo listas de pacotes... Pronto
Construindo árvore de dependências
Lendo informação de estado... Pronto
nodejs is already the newest version (13.13.0-1nodesource1).
Alguns pacotes não puderam ser instalados. Isto pode significar que
você solicitou uma situação impossível ou, se você está usando a
distribuição instável, que alguns pacotes requeridos não foram
criados ainda ou foram retirados da "Incoming".
A informação a seguir pode ajudar a resolver a situação:

Os pacotes a seguir têm dependências desencontradas:
nodejs : Conflita: npm
E: Impossível corrigir problemas, você manteve (hold) pacotes quebrados.

2 - sudo npm install -g @angular/cli
npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
npm ERR! code EEXIST
npm ERR! syscall symlink
npm ERR! path ../lib/node_modules/@angular/cli/bin/ng
npm ERR! dest /usr/bin/ng
npm ERR! errno -17
npm ERR! EEXIST: file already exists, symlink '../lib/node_modules/@angular/cli/bin/ng' -> '/usr/bin/ng'
npm ERR! File exists: /usr/bin/ng
npm ERR! Remove the existing file and try again, or run npm
npm ERR! with --force to overwrite files recklessly.

npm ERR! A complete log of this run can be found in:
npm ERR! /home/anderson/.npm/_logs/2020-04-17T16_25_56_704Z-debug.log

Sou usuário Linux Mint 19.3 Cinnamon, 4.4.8, 5.3.0-46-generic

Alguem consegue me ajudar?

@LeloCorrea Seu erro não está relacionado a request , é um problema com a criação de um link simbólico em seu ambiente local:

npm ERR! EEXIST: file already exists, symlink '../lib/node_modules/@angular/cli/bin/ng' -> '/usr/bin/ng'

@LeloCorrea Seu erro não está relacionado request, é um problema com a criação de um link simbólico no seu ambiente local:

npm ERR! EEXIST: file already exists, symlink '../lib/node_modules/@angular/cli/bin/ng' -> '/usr/bin/ng'

Sabe como posso resolver esse problema?

@LeloCorrea Seu erro não está relacionado request, é um problema com a criação de um link simbólico no seu ambiente local:
npm ERR! EEXIST: file already exists, symlink '../lib/node_modules/@angular/cli/bin/ng' -> '/usr/bin/ng'

Sabe como posso resolver esse problema?

Not the exact same problem, but the solution may be the same. You should start here:

https://stackoverflow.com/questions/48808384/angular-cli-error-path-and-code-eexist

Also, again, this problem is not related to request in any way, you should ask for help about the Angular CLI in the relevant issue tracker.

Qual é a alternativa recomendada? Apenas usando pacotes http / https?

@RonRofe estou usando https://github.com/sindresorhus/got , parece ser um bom sucessor, tem um guia de como migrar a partir do pedido .

@RonRofe há uma lista (WIP) de alternativas aqui: https://github.com/request/request/issues/3143

Estou triste com isso, a solicitação tem sido minha liberdade de escolha desde que me lembro.
Só posso agradecer ao autor e aos colaboradores pelo incrível trabalho que fizeram ao longo dos anos, e espero que sua próxima aventura seja tão empolgante quanto esta.
Saúde!

você pode dar recomendações para alternativas em seu primeiro comentário fixo?

Olá, estou tentando criar um novo projeto angular e tenho este erro:
/ Instalando pacotes ... npm WARN obsoleto [email protected] : a solicitação foi suspensa, consulte https://github.com/request/request/issues/3142
npm WARN obsoleto [email protected] : Chokidar 2 irá quebrar no nó v14 +. Atualize para chokidar 3 com 15x menos dependências.
npm WARN obsoleto [email protected] : fsevents 1 será interrompido no nó v14 +. Atualize para fsevents 2 com grandes melhorias.
npm WARN obsoleto [email protected] : consulte https://github.com/lydell/urix#deprecated
npm WARN obsoleto [email protected] : https://github.com/lydell/resolve-url#deprecated
npm ERR! Fim inesperado da entrada JSON durante a análise perto de '... ": {" @ angular / core ":" 5'

npm ERR! Um registro completo desta execução pode ser encontrado em:
npm ERR! C: \ Users \ dell \ AppData \ Roamingnpm-cache_logs \ 2020-04-21T11_50_16_582Z-debug.log
× Falha na instalação do pacote, veja acima.
O fluxo de trabalho esquemático falhou. Veja acima.
Alguém poderia me ajudar com isso ?

Olá, estou tentando criar um novo projeto angular e tenho este erro:
/ Instalando pacotes ... npm WARN descontinuado [email protected] : a solicitação foi descontinuada, consulte # 3142
npm WARN obsoleto [email protected] : Chokidar 2 irá quebrar no nó v14 +. Atualize para chokidar 3 com 15x menos dependências.
npm WARN obsoleto [email protected] : fsevents 1 será interrompido no nó v14 +. Atualize para fsevents 2 com grandes melhorias.
npm WARN obsoleto [email protected] : consulte https://github.com/lydell/urix#deprecated
npm WARN obsoleto [email protected] : https://github.com/lydell/resolve-url#deprecated
npm ERR! Fim inesperado da entrada JSON durante a análise perto de '... ": {" @ angular / core ":" 5'

npm ERR! Um registro completo desta execução pode ser encontrado em:
npm ERR! C: \ Users \ dell \ AppData \ Roamingnpm-cache_logs \ 2020-04-21T11_50_16_582Z-debug.log
× Falha na instalação do pacote, veja acima.
O fluxo de trabalho esquemático falhou. Veja acima.
Alguém poderia me ajudar com isso ?

eu também

CREATE my-project / angular.json (3598 bytes)
CRIAR my-project / package.json (1286 bytes)
CRIAR meu-projeto / README.md (1026 bytes)
CRIAR meu-projeto / tsconfig.json (489 bytes)
CRIAR meu-projeto / tslint.json (3125 bytes)
CRIAR meu-projeto / .editorconfig (274 bytes)
CRIAR meu-projeto / .gitignore (631 bytes)
CRIAR meu projeto / lista de navegadores (429 bytes)
CRIAR meu-projeto / karma.conf.js (1022 bytes)
CRIAR my-project / tsconfig.app.json (210 bytes)
CRIAR my-project / tsconfig.spec.json (270 bytes)
CRIAR meu-projeto / src / favicon.ico (948 bytes)
CRIAR meu-projeto / src / index.html (295 bytes)
CRIAR meu-projeto / src / main.ts (372 bytes)
CRIAR my-project / src / polyfills.ts (2835 bytes)
CRIAR my-project / src / styles.css (80 bytes)
CRIAR meu-projeto / src / test.ts (753 bytes)
CRIAR meu-projeto / src / ativos / .gitkeep (0 bytes)
CRIAR meu-projeto / src / ambientes / ambiente.prod.ts (51 bytes)
CRIAR meu-projeto / src / ambientes / ambiente.ts (662 bytes)
CRIAR my-project / src / app / app-routing.module.ts (246 bytes)
CRIAR my-project / src / app / app.module.ts (393 bytes)
CRIAR my-project / src / app / app.component.html (25757 bytes)
CRIAR my-project / src / app / app.component.spec.ts (1071 bytes)
CRIAR my-project / src / app / app.component.ts (214 bytes)
CRIAR my-project / src / app / app.component.css (0 bytes)
CRIAR my-project / e2e / protractor.conf.js (808 bytes)
CRIAR meu-projeto / e2e / tsconfig.json (214 bytes)
CRIAR my-project / e2e / src / app.e2e-spec.ts (643 bytes)
CRIAR meu-projeto / e2e / src / app.po.ts (301 bytes)
/ Instalando pacotes ... npm WARN obsoleto [email protected] : TSLint tornou-se obsoleto em favor do ESLint. Consulte https://github.com/palantir/tslint/issues/4534 para obter mais informações.
npm WARN deprecated [email protected] : a solicitação foi descontinuada, consulte https://github.com/request/request/issues/3142
npm WARN obsoleto [email protected] : Atualize para chokidar 3 com 15x menos dependências. Chokidar 2 será interrompido no nó v14.
npm WARN obsoleto [email protected] : consulte https://github.com/lydell/urix#deprecated
npm WARN obsoleto [email protected] : https://github.com/lydell/resolve-url#deprecated
npm ERR! Fim inesperado da entrada JSON durante a análise perto de '.... 0.1 "," systemjs ":" ^ 0.'

npm ERR! Um registro completo desta execução pode ser encontrado em:
npm ERR! C: \ Users \ 92306 \ AppData \ Roamingnpm-cache_logs \ 2020-04-21T16_08_05_350Z-debug.log
× Falha na instalação do pacote, veja acima.
O fluxo de trabalho esquemático falhou. Veja acima.

@ awais0048 @xunyegege seu erro não tem nada a ver com solicitação. Estude a saída real e ela lhe dirá precisamente qual é o erro. Se você tiver mais problemas com o Angular CLI, relate no rastreador de problemas.

@ awais0048 @xunyegege seu erro não tem nada a ver com solicitação. Estude a saída real e ela lhe dirá precisamente qual é o erro. Se você tiver mais problemas com o Angular CLI, relate no rastreador de problemas.

Tentei atualizar o NPM e o nó, mas nenhuma pista. se alguem encontrar solução pode me dizer por favor?

@ANadjia novamente, o erro não tem nada a ver com este pacote. Você deve perguntar no rastreador para Angular CLI.

Olá, Instalando pacotes ... npm WARN obsoleto [email protected] : a solicitação foi suspensa, consulte https://github.com/request/request/issues/3142 npm ERR! Fim inesperado da entrada JSON durante a análise perto de '... ZXQ4dst \ n4bcYaiOdlbvh'
quando eu crio um novo projeto
alguma sugestão

@mohamedelsoufi este é um problema com seu ambiente ou projeto, não com este pacote. O NPM está apenas avisando que este pacote está obsoleto.

@milette
É uma boa ideia manter este thread em execução como um lembrete das consequências de descontinuar um pacote usado em 99% dos projetos no mundo.

@ anton-bot Na verdade, um lembrete de quantas pessoas não fazem RTFM.

@csvan e eles dizem que não é problema deles também
De qualquer maneira, eu finalmente consegui fazer as coisas funcionarem para mim.
Então, basicamente :
1 / i downgrade para o nó js versão 10.13.0;
2 / eu excluí manualmente a pasta npm_cache
3 / execute npm install;
e por magia funcionou

@ANadjia bom ouvir!

A substituição sugerida não é clara. O que devemos usar no lugar?

@johnworthley tudo o que funciona para você. Há uma lista de alternativas sugeridas aqui: https://github.com/request/request/issues/3143

@johnworthley tudo o que funciona para você. Há uma lista de alternativas sugeridas aqui: # 3143

hmm bom lugar https://www.youtube.com/watch?v=riuZHZPcZsg

Ainda podemos usar esta biblioteca mesmo se ela estiver obsoleta? Por favor avise @mikeal

Ainda podemos usar esta biblioteca mesmo se ela estiver obsoleta? Por favor informar

@DokurOmkar Sim. Não há nada que o impeça de usar a biblioteca. É simplesmente um aviso. No entanto, ele está obsoleto por um motivo: existem bibliotecas melhores e mais modernas por aí. Leia este tópico e você encontrará um link para uma lista de bibliotecas alternativas.

não é capaz de criar um novo projeto angular
está falhando devido a -
npm WARN deprecated [email protected] : a solicitação foi descontinuada, consulte https://github.com/request/request/issues/3142

@adibhosale Você tem mais informações? Quais são as outras mensagens no console que você está vendo?

@adibhosale não, não está falhando por causa disso. Em caso afirmativo, é um problema com o angular-cli, não com este pacote. Verifique o resto da saída do log.

@ anton-bot
Responder para -> @adibhosale Você tem mais informações? Quais são as outras mensagens no console que você está vendo?

Este é o erro que estou recebendo ao criar um novo projeto angular.

Instalando pacotes ... npm WARN obsoleto [email protected] : TSLint tornou-se obsoleto em favor do ESLint. Consulte https://github.com/palantir/tslint/issues/4534 para obter mais informações.
npm WARN deprecated [email protected] : a solicitação foi descontinuada, consulte https://github.com/request/request/issues/3142
npm WARN obsoleto [email protected] : Chokidar 2 irá quebrar no nó v14 +. Atualize para chokidar 3 com 15x menos dependências.
npm WARN obsoleto [email protected] : fsevents 1 irá quebrar no nó v14 + e pode estar usando binários inseguros. Atualize para fsevents 2.
npm WARN obsoleto [email protected] : consulte https://github.com/lydell/urix#deprecated
npm WARN obsoleto [email protected] : https://github.com/lydell/resolve-url#deprecated
npm ERR! cb () nunca ligou!

npm ERR! Relate este erro em:
npm ERR! https://npm.community

npm ERR! Um registro completo desta execução pode ser encontrado em:
npm ERR! C: \ Users \ adibh \ AppData \ Roamingnpm-cache_logs \ 2020-05-05T08_46_31_829Z-debug.log
× Falha na instalação do pacote, veja acima.
O fluxo de trabalho esquemático falhou. Veja acima.

Estou confuso sobre por que tantos usuários relatam detalhes totalmente irrelevantes para este problema?

parece que a maioria dos usuários que vieram aqui não tem ideia do que estão fazendo, provavelmente nem entendem o que a palavra obsoleto significa.

mas a última mensagem postada aqui, há mais de uma mensagem de suspensão de uso, por que eles escolhem relatar esse problema? porque alguns usuários já o fizeram e simplesmente continuam?

e o último bit dessa mensagem específica, especificamente informa que o bug do npm deve ser relatado ao npm.community.

os mantenedores aqui, eu acho que deveriam deletar todos os itens de discussão não relevantes para solicitar depreciação e bloquear as discussões aqui.

talvez a mensagem de depreciação do pacote de solicitações deva ser alterada para um link, em vez de problema, como fazem os pacotes lydell / urix e lydell / resolve-url, para que a enxurrada de postagens irrelevantes não apareça aqui.

@glensc Quem diria que descontinuar um pacote usado por quase todos os projetos JS no mundo teria consequências indesejadas!

@glensc , estamos relatando esse problema específico porque no momento da instalação do angular / CLI, recebemos o link para esse problema.

Obrigado :-)

Se disser WARN, significa que não é um ERR. Apenas alguns fatos.

@adibhosale não, você recebe um aviso do NPM que contém um link para este problema do github - entre MUITOS outros links na mesma saída de log. O aviso não tem nada a ver com a falha, você precisa ler o log com mais atenção. Afirma claramente que:

npm ERR! cb() never called!
npm ERR! This is an error with npm itself. Please report this error at:
npm ERR! https://npm.community

e essa é a razão pela qual a instalação falha. Você precisa fazer a devida diligência e descobrir o que causa isso antes de relatar um problema em um pacote que não tem absolutamente nada a ver com isso.

@ anton-bot, você fica dizendo isso. Você tem alguma coisa construtiva para contribuir ou ainda está aqui apenas para trollar?

@csvan @leoskyrocker @glensc Peço desculpas por ter iniciado isso. Estarei cuidando no futuro. Obrigado :-)

Como resolver este problema
não é capaz de criar um projeto angular
edição

////////

deprecated [email protected] : o pedido foi descontinuado, consulte https://github.com/request/request/issues/3142
npm WARN checkPermissions Falta de acesso de gravação a / usr / local / lib / node_modules
npm ERR! código EACCES
npm ERR! acesso syscall
npm ERR! caminho / usr / local / lib / node_modules
npm ERR! errno -13
npm ERR! Erro: EACCES: permissão negada, acesso '/ usr / local / lib / node_modules'
npm ERR! [Erro: EACCES: permissão negada, acesso '/ usr / local / lib / node_modules'] {
npm ERR! errno: -13,
npm ERR! código: 'EACCES',
npm ERR! syscall: 'acesso',
npm ERR! caminho: '/ usr / local / lib / node_modules'
npm ERR! }
npm ERR!
npm ERR! A operação foi rejeitada pelo seu sistema operacional.
npm ERR! É provável que você não tenha permissão para acessar este arquivo como o usuário atual
npm ERR!
npm ERR! Se você acredita que isso pode ser um problema de permissão, verifique novamente o
npm ERR! permissões do arquivo e seus diretórios ou tente executar
npm ERR! o comando novamente como root / administrador.

npm ERR! Um registro completo desta execução pode ser encontrado em:
npm ERR! /Users/vivek/.npm/_logs/2020-05-05T11_48_34_569Z-debug.log

@ vivek08011991 a saída do log explica o que você precisa fazer. Este é um problema quando você tenta instalar o angular globalmente sem usar sudo . Não tem nada a ver com este pacote.

Ei cara, isso tudo é uma merda de conversa, deixa pra lá,
eu vou te dizer a solução
eu tentei 3 dias então eu consegui
primeiro: npm instale npm
seconde: npm uninstall --save react-native-cli
finalmente: npm install -g @ angular / cli

Ei cara, isso tudo é uma merda de conversa, deixa pra lá,
eu vou te dizer a solução
eu tentei 3 dias então eu consegui
primeiro: npm instale npm
seconde: npm uninstall --save react-native-cli
finalmente: npm install -g @ angular / cli

Cara, você estava certo alhamdou lil allah. Por que o Reagir Cli está causando o problema? existem algumas práticas de competição feias aí? obrigado parceiro

preste atenção a este é o rastreador de problemas do módulo request , não angular .

Alguém pode me dizer a alternativa para request ?

Estou lendo isso e prefiro muito mais a API simplista de request :

https://www.twilio.com/blog/2017/08/http-requests-in-node-js.html

@dolanmiu Claro. Qualquer pessoa que leu o tópico que você acabou de postar (ou mesmo pesquisou por _alternative_) poderia dizer que há uma lista de alternativas em https://github.com/request/request/issues/3143.

@dolanmiu @ root / request é um substituto quase sempre

@Richienb entre postman-request (também uma substituição drop-in) e @ root / request, qual é o melhor? postman-request não tem tipificações TypeScript, o que é um problema.

@ anton-bot Definitivamente @ root / request.

Há algum tempo que uso request e concordo com o mikeal. Os módulos nativos do Node foram desenvolvidos ao longo do tempo para corresponder a este módulo request que não existe mais nenhuma razão para usá-lo, a não ser para corrigir repetidamente o código quando uma nova versão de request veio Fora.

request ficará para sempre nas pedras da história; node cresceu. Este é o momento em que precisamos deixar algumas coisas irem. request sempre foi um pioneiro em recursos inovadores e sentirei que sem request , o desenvolvimento de nós não teria sido tão bom.

Como um jovem programador, adorei usar este pacote, mas também sei que para melhorar e construir programas ainda melhores, não se deve demorar mais no passado.

Como um jovem programador, adorei usar este pacote

Isso me fez rir. Como eu jovem programador, usei o Commodore BASIC. :risonho:

@darkRaspberry :

  1. leia seu relatório de erro até o fim, não apenas a primeira linha, está escrito claramente qual é o erro e até mesmo uma sugestão do que fazer. você claramente não leu além da primeira linha.
  2. você pesquisou seu erro no Google?
  3. leia as discussões anteriores e explique por que você postou isso aqui, seu relatório de problema não tem nada a ver com o módulo de solicitações.

apenas desabilite seu antivírus você não obterá nenhum erro
Obrigado !!!

@glensc Reinstalei completamente meu terminal para remover qualquer outra versão do nó e tentei "sudo"
E funcionou.
Estou usando a versão de nodejs usando curl para adicionar node js em meu PPA.

e aqui funcionou
dark<strong i="10">@darkRaspberry</strong>:~$ sudo npm install firebase-tools -g

npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
/usr/bin/firebase -> /usr/lib/node_modules/firebase-tools/lib/bin/firebase.js
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@~2.1.2 (node_modules/firebase-tools/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"})

+ [email protected]
updated 2 packages in 42.696s

Isso me emocionou. E: reverência: a todos os contribuidores!

image

@ sudarsan2017 Esse erro não está relacionado a request forma alguma

Olá! pessoal passe pelo mesmo problema no Windows e resolvi usando o comando

npm install [email protected]

Espero que de certo o de vocês.

Estou recebendo o aviso npm npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142

Como faço para corrigir isso?

@ aman78600 Não há como consertar.

Estou recebendo o aviso npm npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142

@ aman78600 Não precisa de conserto. É apenas um aviso de que request has been deprecated .

Seu NPM diz para vir aqui em busca de alternativas, mas não as vejo.

Seu NPM diz para vir aqui em busca de alternativas, mas não as vejo.

@skeddles Se você tivesse pressionado Control-F e pesquisado por alternatives , teria encontrado o link para https://github.com/request/request/issues/3143.

Não consigo instalar o vue-cli a partir deste comando npm install -g @ vue / cli mostra a mensagem: npm WARN deprecated [email protected] : request foi deprecated

@somnangrom Isso não pode ser verdade, tenho certeza de que há algumas outras mensagens no console e não apenas esta linha.

Eu realmente queria dizer muito obrigado por trabalhar neste pacote. Me ajudou muito nos meus projetos. Razões totalmente compreensíveis pelas quais o suporte foi interrompido.

Vocês fizeram um trabalho incrível, deveriam se orgulhar!

🤝

Não consigo instalar a versão mais recente do Angular CLI.
Versão de 64 bits do Nodejs: 12.18.1
versão npm: 6.13.6
Quando executo npm install -g @ angular / cli @ latest para instalar a versão mais recente do Angular CLI, recebo o seguinte aviso de erro
npm WARN deprecated [email protected] : a solicitação foi descontinuada, consulte https://github.com/request/request/issues/3142

A instalação é interrompida com a mensagem: postinstall: sill install executeActions
Por favor me ajude a resolver este problema

Não consigo instalar a versão mais recente do Angular CLI.
Eu instalei o Nodejs no meu laptop Windows 10 Pro
Versão de 64 bits do Nodejs: 12.18.1versão npm: 6.13.6
Quando executo npm install -g @ angular / cli @ latest para instalar a versão mais recente do Angular CLI, recebo o seguinte aviso de erro
npm WARN descontinuado [email protected] : o pedido foi descontinuado, consulte # 3142

A instalação é interrompida com a mensagem: postinstall: sill install executeActions
Por favor me ajude a resolver este problema

@anjaikr e @ aman78600 consulte https://github.com/angular/angular-cli/wiki/stories-1.0-update para instalar a versão mais recente espero que ajude

npm install -g json-server não está funcionando, o que devo fazer?

Ainda podemos usá-lo para ações básicas, certo?

Estou recebendo um erro ao instalar o angular 5, tentei instalar, mas está mostrando que a solicitação foi descontinuada ... o que devo fazer

@mikeal Para ser claro, você pretende que bent substitua request ?

Olá,

Alguém sabe qual é o problema:
npm i -g json-server
npm WARN deprecated [email protected] : a solicitação foi descontinuada, consulte https://github.com/request/request/issues/3142
npm WARN obsoleto [email protected] : esta biblioteca não é mais compatível

Valeu.

Uma das razões mais idiotas que ouvi para depreciação. Imagine se o Google e a Microsoft retirassem todos os seus produtos das prateleiras porque é "muito mais difícil para novas bibliotecas realizar tarefas semelhantes obter adoção" e porque "há uma transição acontecendo agora no ecossistema para esses padrões". Completamente ridículo.

image

Primeiramente mostre meu respeito por este repo, entretanto, para ser honesto, o que @cypheron disse faz sentido.

@ Wenjie-Shao Não tem sentido, receio. Sem o aviso de descontinuação, ainda mais pessoas estariam baixando e usando esta biblioteca sem perceber que ela estava desatualizada. @mikeal prestou um grande serviço à comunidade ao descontinuar formalmente esta biblioteca em vez de apenas deixá-la apodrecer. Talvez o erro tenha sido criar um link para este tópico.

Estou apenas tentando tatear o tutorial para configurar surge.sh.

Parece que vocês têm muita coisa acontecendo aqui. Isso vai me ferrar aqui no novo futuro se eu simplesmente ignorar os avisos e for embora?

Uma das razões mais idiotas que ouvi para depreciação. Imagine se o Google e a Microsoft retirassem todos os seus produtos das prateleiras porque é "muito mais difícil para novas bibliotecas realizar tarefas semelhantes obter adoção" e porque "há uma transição acontecendo agora no ecossistema para esses padrões". Completamente ridículo.

Mas eles conseguiram. E frequentemente. Existem muitos, muitos produtos desses gigantes do software que não existem mais ou estão atualmente obsoletos e não estão recebendo nenhuma atualização. Já ouviu falar, digamos, do Windows 95 ou do FoxPro? Todo projeto de software acabará chegando ao fim por um motivo ou outro. E os autores de Request também não o estão retirando das prateleiras, eles estão interrompendo novos desenvolvimentos. Correções de bugs críticos ainda acontecerão por um tempo e se o seu projeto depender disso - sem problemas. Você ainda pode continuar a usá-lo.

Mas se você começar um novo projeto, existem alternativas melhores e mais modernas por aí. A linguagem evoluiu, há maneiras melhores de fazer as mesmas coisas agora, mas o Request não pode acompanhá-la porque precisa dos projetos legados para trabalhar com ela. Para novos projetos, é inferior ao ideal.

Portanto, esta decisão faz todo o sentido para mim. Deixe Request onde está para que os projetos legados ainda possam continuar a usá-lo, mas para novos projetos, recomende novas bibliotecas.

Existe algum motivo específico pelo qual alguém usaria request ao invés de axios?

Existe algum motivo específico pelo qual alguém usaria request ao invés de axios?

Certo. Em cima da minha cabeça:

  • Você está acostumado ou tem muita experiência com isso
  • Seu projeto já usa em todos os lugares. Mudar tudo levaria semanas, senão meses, de reescrita de código.
  • As diretrizes de codificação da empresa / projeto exigem esta biblioteca (ou permite apenas bibliotecas com certos requisitos de "maturidade")
  • Uma biblioteca de terceiros exige isso (e talvez até exija que você o use ao trabalhar com a biblioteca). Pontos extras se a biblioteca não tiver alternativas.
  • Você é um estudante e o curso que está fazendo ensina explicitamente sobre a solicitação e a tem em exames / trabalhos de casa

Em essência, todas essas são variações do mesmo tema - você precisa trabalhar com algumas coisas legadas que ainda não se adaptaram às últimas tendências. Isso tende a acontecer com bastante regularidade na vida real.

npm WARN deprecated [email protected] : a solicitação foi descontinuada, consulte https://github.com/request/request/issues/3142
npm WARN obsoleto @ hapi / @hapi e voltando para 'joi' (https://github.com/sideway/joi/issues/2411)
npm WARN deprecated @ hapi /
npm WARN deprecated @ hapi /
npm WARN deprecated @ hapi /
npm WARN deprecated @ hapi /
npm WARN obsoleto [email protected] : esta biblioteca não é mais compatível
npm WARN obsoleto [email protected] : consulte https://github.com/lydell/urix#deprecated
npm WARN obsoleto [email protected] : https://github.com/lydell/resolve-url#deprecated
npm WARN obsoleto [email protected] : Chokidar 2 irá quebrar no nó v14 +. Atualize para chokidar 3 com 15x menos dependências.
npm WARN obsoleto [email protected] : fsevents 1 irá quebrar no nó v14 + e pode estar usando binários inseguros. Atualize para fsevents 2.

POR QUE???? TODA A MINHA INSTALAÇÃO GLOBAL DO NPM SEMPRE ME AVISO QUE ESTÁ DESCONTINUADO ?? COMO CONSERTAR ISTO

TENTO DESINSTALAR O NODEJS
OU
ATUALIZANDO NPM
MAS NÃO FUNCIONA
POR FAVOR ME AJUDE

ESTÁ DESCONTINUADO.
VOCÊ NÃO PODE CORRIGIR ISSO.
IGNORE O AVISO.

Ou reescreva seu código para que ele não use Request.

@acatzk

Experimente

npm install -s (ou --silent)
ou

npm install -q (ou --quiet)

silenciar avisos

Este tópico é o melhor.

Oi. Eu sou novo em APIs. Eu estava tentando instalar o pacote de solicitação e ele disse que agora está obsoleto. Tentei pesquisar e ver o que está acontecendo, mas agradeceria se alguém pudesse me explicar o que posso fazer agora. Isso significa que o pacote de solicitação não pode mais ser usado? Que outro pacote posso usar para fazer o mesmo trabalho?

@ mohammed3736 Não, ainda pode ser usado. Mas não será atualizado. Não receberá novos recursos. Pode haver algumas correções de bugs por um tempo, mas não por muito tempo. E o aviso sempre estará lá. Essencialmente, eles estão abandonando o projeto. Se você quiser fazer alguma alteração, precisará fazer você mesmo. Afinal - todo o código-fonte para solicitação ainda está disponível. Você pode fazer seu próprio garfo e fazer o que quiser com ele.

Se você estiver escrevendo um novo projeto, é melhor tentar outra biblioteca mais moderna. Por exemplo, usamos Axios, mas tenho certeza que existem outros.

Vou fazer a seguinte pergunta em minhas entrevistas agora, em vez do Fizzbuzz:

You have faced the following message in your console.

What should you do about it and how do you fix it?

> npm WARN deprecated [email protected]: request has been deprecated, see #3142

@ anton-bot Isso é fácil, a resposta é: "Eu clico no link, não leio nada, mas vou até o final do tópico e posto a mesma pergunta que todos os outros."

Eu consigo o emprego?

@ anton-bot Isso é fácil, a resposta é: "Eu clico no link, não leio nada, mas vou até o final do tópico e posto a mesma pergunta que todos os outros."

Eu consigo o emprego?

O motivo de eu estar perguntando é porque continuo obtendo 401s no log do console. E o módulo de solicitação não está funcionando para mim. Estou tentando usar a API de bitcoinaverage e de https://any-api.com/ e nenhum deles estava funcionando. Quando eu entro em localhost3000, o html funciona e eu obtenho a página, mas quando pressiono o botão para obter o resultado, meu console trava. Meu log do console diz que o aplicativo travou ou 401 para o statusCode e no navegador. Observe também que nenhum dos meus proxies está habilitado. Tentei de tudo, mas continuo recebendo erros. SE você puder me ajudar eu agradeceria.

@ mohammed3736 - Este é o lugar errado para perguntar. Além disso, tenho 99,99% de certeza de que a culpa não é da biblioteca de solicitações. Há um bug em seu programa e você mesmo o criou. Você também terá que descobrir por si mesmo. Se você ainda precisar de ajuda, tente pedir StackOverflow, mas inclua o código que não funciona. O melhor de tudo - tente fazer o menor programa possível que trava e mostre o código-fonte.

Eu também vim aqui para fazer uma pergunta, mas ... o que há com todos os ataques racistas aqui? vocês são inacreditáveis.

E sim, ainda não tenho ideia de por que meu código não funciona. O único erro no console me traz aqui.

Verifique seu privilégio e divirta-se

Eu também vim aqui para fazer uma pergunta, mas ... o que há com todos os ataques racistas aqui? vocês são inacreditáveis.

E sim, ainda não tenho ideia de por que meu código não funciona. O único erro no console me traz aqui.

Verifique seu privilégio e divirta-se

A que ataques racistas você está se referindo? Isso soa muito ruim

Mesmo problema observado. Por favor ajude se alguém souber como resolver

[email protected] : o pedido foi descontinuado, consulte https://github.com/request/request/issues/3142

@ HaseebAhmed49 o pacote npm "request" sendo descontinuado não é um problema por si só. a mensagem é para os desenvolvedores de projetos de biblioteca.

Não se preocupe com isso. Muitas pessoas no github me disseram que está tudo bem. Isto
basicamente significa que o pacote não terá novos recursos adicionados
a ele mais e não será atualizado, mas ainda está perfeitamente bem para
usar. Eu usei e ficou bom.

Na segunda-feira, 14 de setembro de 2020 às 23:57 Elan Ruusamäe [email protected]
escreveu:

>
>

@ HaseebAhmed49 https://github.com/HaseebAhmed49 o "pedido" npm
pacote obsoleto não é um problema por si só. a mensagem é para a biblioteca
desenvolvedores de projetos.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/request/request/issues/3142#issuecomment-692279572 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AQFTBJ255VRYJW4VMUFQQ23SFZYSZANCNFSM4HCP6LRA
.

mas ainda está perfeitamente bom de usar

Na verdade. Pode funcionar _por agora_, mas você nunca deve ter uma dependência explícita de um pacote que não receberá mais correções de bug e segurança. Você está colocando seu aplicativo (e usuários) em risco significativo de quebra repentina e vazamentos de segurança quando aquele pacote eventualmente _parar_ de funcionar (o que quase certamente irá). Isso é especialmente verdadeiro para um pacote como request que fornece algo tão crucial e sensível quanto fazer solicitações de rede.

Um aviso de reprovação é um aviso sério para começar a migrar para outro lugar. Várias alternativas já foram mencionadas (e repetidas) neste tópico.

Olá a todos, também tive esses problemas obsoletos
então o que fiz foi desinstalar o nodejs e baixar os recursos mais recentes do nodejs
que é 14.10.1 Recursos mais recentes atuais
https://nodejs.org/en/

e exclua todos os npm globais instalados que você tem no computador

e é isso...

todos aqueles obsoletos se foram ...

@acatzk wtf lmao

Esta biblioteca está obsoleta . Se houver um bug, nada será feito para corrigi-lo. Se houver um problema de segurança, nada será feito para corrigi-lo.

Você não deve usar isso.

@davwheat obrigado

quais as alternativas deste módulo de solicitação?

Coisas que podemos fazer - por favor, discuta e seja voluntário!

  • [] atualizar leia-me com o estado atual do projeto
  • [] atualizar pipeline de publicação ci @mikeal
  • [] forneça um documento com algumas orientações sobre as request alternativas # 3143
  • [] adicione uma mensagem de aviso na instalação do pacote para usar outro pacote e consulte o documento
  • [] escolha uma data para interromper o suporte (eu voto 6 meses, mas 12 é provavelmente mais amigável)
  • [] feche todas as solicitações de recursos e prs de recursos
  • [] revisar e mesclar as correções de bugs relevantes
  • [] adicionar problema do github e modelos de RP explicando que os recursos não serão mesclados
  • [] descontinuar a próxima versão principal ( 3.x ) para que o projeto em manutenção ativa receba um aviso, mas os projetos mais antigos continuam como de costume

Alguma atualização de quem está fazendo o quê neste momento?

Para aqueles que procuram uma alternativa sólida com suporte do Google (além das em https://github.com/request/request/issues/3143), eu recomendo https://github.com/googleapis/gaxios. Usei em um projeto recente e está excelente até agora.

Quais são as alternativas? Sua página npm diz For more information about why request is deprecated and possible alternatives refer to {the link to this page}

3143

Registro npm WARN Usando dados desatualizados de https://registry.npmjs.org/ devido a um erro de solicitação durante a revalidação.
npm WARN deprecated [email protected] : a solicitação foi descontinuada, consulte https://github.com/request/request/issues/3142

@thbestforyourbizdeployment sim.

Obrigado.

pode me ajudar?

npm WARN deprecated [email protected]: a solicitação foi descontinuada, consulte https://github.com/request/request/issues/3142
npm WARN obsoleto [email protected]: esta biblioteca não é mais compatível
npm ERR! código EEXIST
npm ERR! link simbólico syscall
npm ERR! caminho ../lib/node_modules/firebase-tools/lib/bin/firebase.js
npm ERR! dest / usr / local / bin / firebase
npm ERR! errno -17
npm ERR! EEXIST: o arquivo já existe, link simbólico '../lib/node_modules/firebase-tools/lib/bin/firebase.js' -> '/ usr / local / bin / firebase'
npm ERR! O arquivo existe: / usr / local / bin / firebase
npm ERR! Remova o arquivo existente e tente novamente ou execute o npm
npm ERR! com --force para sobrescrever arquivos imprudentemente.

npm ERR! Um registro completo desta execução pode ser encontrado em:
npm ERR! /Users/bahar/.npm/_logs/2020-11-18T17_07_43_310Z-debug.log

@baharozcelik Não há nada para ajudá-lo.

Leitura. Edição.

sudo npm install --global gulp-cli
tente assim

Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

mlegenhausen picture mlegenhausen  ·  4Comentários

jasonxia23 picture jasonxia23  ·  3Comentários

victor0402 picture victor0402  ·  4Comentários

jdarling picture jdarling  ·  3Comentários

pixarfilmz112 picture pixarfilmz112  ·  3Comentários