Request: Pasado, presente y futuro de la solicitud

Creado en 30 mar. 2019  ·  352Comentarios  ·  Fuente: request/request

Antes de entrar en detalles y razonar, iré directo al grano. Lo más valioso que puede hacer request por el ecosistema de JavaScript es entrar en modo de mantenimiento y dejar de considerar nuevas funciones o versiones importantes.

Disculpas de antemano a los otros confirmadores de request que han estado haciendo todo lo posible para mejorarlo, pero es lo mejor.

2009

La primera versión de request fue uno de los primeros módulos creados para el ecosistema Node.js. Las primeras versiones se escribieron en API que son anteriores a la interfaz de devolución de llamada estándar, streams, node_modules y npm. Durante los primeros años, request y Node.js evolucionaron juntos, cada uno aprendiendo del otro. A medida que Node.js mejoró y migró las interfaces centrales, también lo solicitó. A medida que la solicitud adoptó cambios en la biblioteca http central y las transmisiones, también informó mejoras como el evento pipe (que habilitó el proxy de una línea de request ) y una de las muchas reescrituras de Core http (la uno que tenía que escribir).

npm

request fue uno de los primeros módulos agregados al registro npm. A medida que el npm creció, también lo hizo la dependencia de request . Incluso ahora, cuando npm se usa mucho más para el front-end que para el back-end, request sigue siendo uno de los módulos más dependientes del registro. Mientras escribo esto, los módulos de 41K dependen de la solicitud y se descargan 14 millones de veces a la semana.

El lugar que tiene request en el ecosistema de Node.js ya no es el de un innovador sino el de un incumbente. Si busca en Google cómo hacer algo con HTTP en Node.js, es probable que los ejemplos muestren request como cliente y express como servidor. Esto tiene dos efectos notablemente negativos.

Es mucho más difícil para las nuevas bibliotecas que realizan tareas similares lograr la adopción debido a la posición actual que request tiene sobre el ecosistema. También es muy difícil cambiar la solicitud de una manera significativa, ya que el cambio no solo puede no ser adoptado por la mayoría de sus dependientes, sino que lo desalinearía con las miles de publicaciones de blog y las respuestas de desbordamiento de la pila que usan request .

JavaScript moderno

Los últimos años han sido dramáticos en JavaScript. Las características de las que la gente había hablado durante años iban desde las ideas hasta los estándares y las características de las que puede depender de manera confiable en la mayoría de los entornos. La velocidad a la que se han adoptado es asombrosa, principalmente gracias a los navegadores que se actualizan automáticamente y a un programa de lanzamiento agresivo de Node.js.

Los patrones en el núcleo de request están desactualizados. Algunas personas podrían discutir con esa evaluación, y yo sé quiénes son, así que no me sorprenderá, pero es cierto. A menudo he sido escéptico sobre el impacto que tendrían algunas de estas características solo para encontrarme adoptándolas al por mayor poco después de que estén disponibles solo en la última versión de Node.js.

Ahora se está produciendo una transición en el ecosistema a estos patrones. Lo desordenado que será eso todavía está en el aire y no voy a intentar leer las hojas de té y descubrir cómo se ve el futuro en ese sentido. La pregunta para request es "¿Intentamos sobrevivir a través de esa transición?" Hace un año pensaba que la respuesta era obvia y que lo haríamos, pero ahora estoy convencido de lo contrario.

Una versión de request escrita para adoptar realmente estos nuevos patrones de lenguaje es, efectivamente, un nuevo módulo. Ya he explorado este espacio un poco y tengo un proyecto con el que estoy bastante contento, pero es incompatible con request en todas las formas imaginables. ¿Cuál es el valor de una versión de request que es incompatible con los patrones antiguos pero que no acepta completamente los nuevos? ¿De qué sirve ser parcialmente compatible cuando hay todo un mundo de módulos nuevos, escritos por nuevos desarrolladores, que están reconsiderando estos problemas con estos patrones en mente?

Lo mejor para estos nuevos módulos es que request se desvanezcan lentamente, convirtiéndose eventualmente en una memoria más de esa pila heredada. Tomar la posición que request tiene ahora y aprovecharla para una mayor proporción de la próxima generación de desarrolladores sería un flaco favor para esos desarrolladores, ya que los alejaría de mejores módulos que no tienen la carga de request Historial de

Modo de mantenimiento

Este es el plan.

  • request dejará de aceptar nuevas funciones.
  • request dejará de considerar cambios importantes.
  • Los confirmadores que aún están activos intentarán fusionar las correcciones de manera oportuna, aunque sin promesas.
  • Las versiones se automatizarán por completo y se publicará cualquier combinación con la versión maestra. Ya construí esto para algunos otros proyectos usando acciones de GitHub .

    • Tendremos que eliminar a los colaboradores inactivos y hacer cumplir la 2fa, porque los derechos de confirmación se convertirán efectivamente en derechos de publicación de npm.

neverstale

Comentario más útil

Apoyo completamente esto, creo que un mensaje de advertencia y / o desaprobar nuevas versiones está en orden.

En cuanto al cambio en el proceso y las pautas, hace que mi trabajo sea mucho más fácil 👌

Todos 352 comentarios

Apoyo completamente esto, creo que un mensaje de advertencia y / o desaprobar nuevas versiones está en orden.

En cuanto al cambio en el proceso y las pautas, hace que mi trabajo sea mucho más fácil 👌

Muy bien dicho @mikeal. Estoy fijando este problema para ganar más visibilidad.

Cosas que podríamos hacer - ¡discuta y sea voluntario!

  • [] actualiza el archivo Léame con el estado actual del proyecto
  • [] actualizar la canalización de publicaciones de ci @mikeal
  • [] proporciona un documento con orientación sobre las alternativas de request https://github.com/request/request/issues/3143
  • [] agregue un mensaje de advertencia al instalar el paquete para usar otro paquete y hacer referencia al documento
  • [] elige una fecha para suspender el apoyo (voto 6 meses, pero 12 es probablemente más amigable)
  • [] cerrar todas las solicitudes de funciones y prs de funciones
  • [] revisar y fusionar las correcciones de errores relevantes
  • [] agregue el problema de github y las plantillas de relaciones públicas que explican que las características no se fusionarán
  • [] desaprueba la próxima versión principal ( 3.x ) para que los proyectos en mantenimiento activo reciban una advertencia, pero los proyectos más antiguos continúan como de costumbre

¡Tiene mucho sentido! También adoptaré lentamente esta política para la familia request-promise . ¡Saludos a sus importantes contribuciones al ecosistema de nodos!

desaprobar el último paquete npm y desaprobarlo automáticamente al publicarlo

Tenga cuidado con la obsolescencia. Como escribió Mikael anteriormente, hay 41K módulos dependiendo de request . Muchos de estos módulos son útiles en el estado actual y funcionan bien para sus usuarios, pero es posible que sus mantenedores no tengan tiempo de reelaborar esos módulos para usar algo más que request . Al desaprobar request en el momento de la instalación, básicamente desaprobará una gran parte del ecosistema del módulo npm.

A mi modo de ver, el modo de mantenimiento no es lo mismo que la desaprobación.

  • Modo de mantenimiento = arreglaremos errores y vulnerabilidades de seguridad para que pueda seguir usando este paquete.
  • Desaprobación = nadie debería seguir usando este paquete. Esto suele ocurrir cuando el módulo se abandona y no recibirá más errores o correcciones de seguridad.

Te escucho. El texto completo

desaprobar el último paquete npm y desaprobarlo automáticamente al publicarlo a través de ci __ (¿tal vez después de que se haya detenido el soporte?) __

Creo que eventualmente deberíamos desaprobar request porque no quiero que los nuevos proyectos lo usen.
He estado tratando de clasificar los problemas y reducirlos a una lista que podamos resolver, pero hay errores que no podemos corregir sin un cambio importante. Por lo tanto, no se solucionarán y los nuevos usuarios tendrán problemas.

Por ejemplo, al seguir las redirecciones se pierden los cuerpos de las solicitudes y las cookies, y el análisis de URL para eliminar las rutas relativas son errores, pero no estoy seguro de que se solucionen alguna vez.

Tal vez la desaprobación no sea la respuesta correcta, pero no sé de qué otra manera abordar eso.

¿Tiene sentido?

Mejoremos la versión principal cuando la desaprovechemos. De esa manera, la mayoría de las personas que dependen del proyecto no verán este error hasta que intenten actualizar a una nueva especialización, lo que significa que lo están desarrollando activamente y realmente deberían buscar una alternativa.

Estoy orgulloso de haber sido parte de la historia de request . También echaré un vistazo a bent , parece interesante, y _pequeño_, que es más importante para mí en estos días.

Tendremos que eliminar a los colaboradores inactivos y hacer cumplir la 2fa, porque los derechos de confirmación se convertirán efectivamente en derechos de publicación de npm.

Bien para sacarme.

Creo que eventualmente deberíamos desaprobar la solicitud porque no quiero que los nuevos proyectos la usen.

Como programador que está MUY agradecido por el módulo y que lo usa todo el tiempo QUIERO usarlo en nuevos proyectos.

Esta decisión debe haber sido muy difícil de tomar, pero es sumamente encomiable. Bien hecho.

Estoy orgulloso de haber utilizado esta increíble herramienta. Obligó a la comunidad a mejorar. 🙏
Si necesita ayuda para su mantenimiento, no dude en ponerse en contacto conmigo.

Si bien respeto su decisión, le pediría que considere cuánto del mundo real, la producción, el código se basa actualmente en la solicitud. Es mucho más de lo que incluso las estadísticas de NPM pueden decirle. Entiendo completamente querer pasar a algo nuevo y hacer algo de una manera nueva y más interesante ... este es el ecosistema de JavaScript después de todo, tengo que perseguir lo nuevo. Pero considere la cantidad de tiempo y dinero que le estaría costando a las organizaciones de ingeniería profesionales mediante una solicitud de depreciación al por mayor. Si desea dejarlo en modo de mantenimiento, está bien, pero comprenda que muchas personas no tienen absolutamente ninguna razón práctica para cambiar las bibliotecas. Obligar a la gente a cambiar debido a la ideología conducirá a la frustración.

Independientemente, gracias por el arduo trabajo que todos han realizado en esta biblioteca.

Me pregunto qué biblioteca podría considerarse moderna y recomendada ahora. Superagent está principalmente en modo de mantenimiento en este momento, axios no demasiado activo en conjunto.

Solo una nota rápida para agradecerle (y a todos los demás colaboradores) por todo el arduo trabajo a lo largo de los años en este módulo; fue uno de los primeros que usé cuando comencé con Node, por lo que siempre tendrá un lugar especial en mi corazón.

Mejoremos la versión principal cuando la desaprovechemos. De esa manera, la mayoría de las personas que dependen del proyecto no verán este error hasta que intenten actualizar a una nueva especialización, lo que significa que lo están desarrollando activamente y realmente deberían buscar una alternativa.

Creo que esta sigue siendo una solución viable para la mención anterior.

@kibertoad Parece que @mikeal está trabajando en https://github.com/mikeal/bent . He estado usando https://github.com/sindresorhus/got durante muchos años y está bien respaldado y evolucionando.

Con toda esta charla y la posibilidad de que se desaproveche, creo que tiene que haber una mención igual de un módulo de reemplazo de madurez actual, de utilidad paralela. No podemos simplemente anunciar su final y luego sugerir nada, o un reemplazo de mucha menos madurez y confianza. La solicitud se utiliza en aplicaciones serias. ¿Por qué importa esto? Porque a pesar de todos sus "patrones obsoletos en su esencia", funciona a diario, por miles. No se trata del mundo perfecto, sino del mundo real. ¿Cuál es el reemplazo real, de confianza, el día en que la solicitud se pone en modo de mantenimiento o se desaprueba? Eso es un imperativo.

Puede encontrar esa discusión aquí https://github.com/request/request/issues/3143

Puede encontrar un plan de trabajo actual (cuyos comentarios directos son bienvenidos) se puede encontrar aquí https://github.com/request/request/issues/3142#issuecomment -478303334

¡Gracias por tu trabajo en request !

Los patrones en el núcleo de la solicitud están desactualizados.

Los patrones cambian cada pocos meses y años, especialmente en la comunidad de JavaScript. ¿No son las razones por las que se creó originalmente request todavía válidas en la actualidad?

request tiene 10 años de confirmaciones, estabilidad y pruebas. ¿Por qué empezar de cero? ¿No se trata simplemente de añadir más "fatiga de JavaScript", lo que da como resultado que más bibliotecas hagan lo mismo: solicitudes HTTP?

Es triste ver que una biblioteca tan importante e histórica en la historia de Node desaparece porque las transmisiones y las devoluciones de llamada ya no son lujosas en 2019.

No creo que sea realmente necesario desaprobar la biblioteca, ha existido durante unos 10 años, se usa en muchos lugares y es bastante estable, y al final. todo lo que hace es realizar solicitudes HTTP, ¿qué más necesitaría la biblioteca? ¿Soporte para la moda JS del mes? 👎

Los confirmadores que todavía están activos intentarán fusionar las correcciones de manera oportuna, aunque sin promesas .

ba-dum-chhh! 🥁

Esta es una depreciación responsable. Bien comunicado, con un plan a seguir. Creo que otros mantenedores de OSS pueden considerar esto como un estándar al que aspirar.

Esto es mucho mejor que olvidarse de un paquete y permitir que personas al azar (que pueden inyectar puertas traseras en el código) ingresen como mantenedores para que se hagan cargo cuando ya no le importe.

Request fue un gran paquete y le agradecemos enormemente sus contribuciones al ecosistema de nodos inicial. Tiene razón en su evaluación de que el estilo de devolución de llamada ya no es JavaScript idiomático, y hay otros paquetes como fetch que reflejan los estándares WHATWG.

@stcktrce Exactamente, la biblioteca no necesita nada más, funciona tal como está. Pero ha habido importantes mejoras en todo el ecosistema. Dejar de lado la biblioteca es solo marcar la oportunidad para que otros revisen bibliotecas nuevas y más modernas en lugar de simplemente confiar en las más populares.

@mikeal gracias por todos sus esfuerzos en la biblioteca ( r2 también) y el ecosistema. Además, por establecer esta precedencia de una depreciación bien pensada y planificada en el ecosistema.

Mejoremos la versión principal cuando la desaprovechemos. De esa manera, la mayoría de las personas que dependen del proyecto no verán este error hasta que intenten actualizar a una nueva especialización, lo que significa que lo están desarrollando activamente y realmente deberían buscar una alternativa.

@mikeal No creo que sea una buena idea.

El problema es que la mayoría de los reemplazos son de menor calidad que la solicitada. Me acabo de mudar a request desde axios aproximadamente una semana.

Axios tiene errores persistentes de varios años en torno al soporte de proxy, la modificación de agentes https y las excepciones de promesa no controladas. Solo los averigua después de invertir mucho en axios.

Para los nuevos usuarios, axios parece superficialmente tan bueno como la solicitud (número similar de usuarios, promesas por diseño, etc.)

Gracias por request :)

Si alguien está buscando una biblioteca HTTP mínima basada en promesas con filtros enchufables y un buen soporte para transmisiones, puede consultar httplease . Lo hemos estado usando durante algunos años en producción.

Me encanta el módulo de solicitud Muchas gracias.
¿Quiere decir que la solicitud se concentra demasiado para evitar que salga otro módulo nuevo?

Si hay errores específicos en características comparables en otras bibliotecas, me gustaría identificarlos específicamente. El soporte de proxy es una característica compleja y tener un caso de prueba que solicite pasa pero otras bibliotecas fallan es muy valioso.

@reconbot en el último axios (^ 0.18.0) no puede conectarse a un sitio https través de un servidor proxy. hacerlo da como resultado EPROTO errores. este es un error abierto con respecto a esto, pero el problema se remonta a años: https://github.com/axios/axios/issues/1981

editar: específicamente, no puede usar axios para realizar solicitudes https a través de un proxy http. tal vez un proxy https dedicado funcione, no lo intenté.

Espero que las correcciones no se consideren características nuevas, como mi solicitud de extracción para el Tamaño de respuesta máximo, que veo como una característica estándar requerida de cualquier biblioteca madura.

También revisé otras bibliotecas de solicitudes antes de elegir esta y la mayoría de ellas son muy problemáticas, incompletas y con errores. Sus docs tampoco miden. Realmente no veo qué puede traer otra biblioteca, excepto código y errores no probados, no es como si hubiera un nuevo enfoque para realizar solicitudes HTTP. Se trata de envolver el módulo http / https y proporcionar valores predeterminados cuerdos, como la respuesta de almacenamiento en búfer, la decodificación de respuestas y, por supuesto, la capacidad de prometer todo . El mayor problema de esta biblioteca aquí es el objetivo de la compatibilidad total, tratar de ser compatible con cosas heredadas solo trae dolor y prácticas de codificación heredadas. Pero esto se puede solucionar de muchas formas. Hay una buena base que se puede refactorizar en algo elegante, moderno y minimalista. Y sobre todo confiable. Hay muchas formas de hacer esto: dividir en más archivos, usar ECMA6 con Babel o Typescript.

Ningún desarrollador en su sano juicio quiere 10 bibliotecas que hagan lo mismo pero que carezcan de características diferentes, tengan errores, no estén documentadas. Esta biblioteca realmente funciona y estoy agradecido por ella y espero que no esté obsoleta, sino que reviva.

Las correcciones no se consideran características nuevas. Las correcciones se fusionarán durante al menos un año, posiblemente incluso más.

-Mikeal


De: mivanovaxway [email protected]
Enviado: jueves 11 de abril de 2019 2:38 a. M.
Para: solicitud / solicitud
Cc: Mikeal Rogers; Mencionar
Asunto: Re: [solicitud / solicitud] Pasado, presente y futuro de la solicitud (# 3142)

Espero que las correcciones no se consideren características nuevas, como mi solicitud de extracción para el Tamaño de respuesta máximo, que veo como una característica estándar requerida de cualquier biblioteca madura.

También revisé otras bibliotecas de solicitudes antes de elegir esta y la mayoría de ellas son muy problemáticas, incompletas y con errores. Sus docs tampoco miden. Realmente no veo qué puede traer otra biblioteca, excepto código y errores no probados, no es como si hubiera un nuevo enfoque para realizar solicitudes HTTP. Se trata de envolver el módulo http / https y proporcionar valores predeterminados cuerdos, como la respuesta de almacenamiento en búfer, la decodificación de respuestas y, por supuesto, la capacidad de prometer todo. El mayor problema de esta biblioteca aquí es el objetivo de la compatibilidad total, tratar de ser compatible con cosas heredadas solo trae dolor y prácticas de codificación heredadas. Pero esto se puede solucionar de muchas formas. Hay una buena base que se puede refactorizar en algo elegante, moderno y minimalista. Y sobre todo confiable. Hay muchas formas de hacer esto: dividir en más archivos, usar ECMA6 con Babel o Typescript.

Ningún desarrollador en su sano juicio quiere 10 bibliotecas que hagan lo mismo pero que carezcan de características diferentes, tengan errores, no estén documentadas. Esta biblioteca realmente funciona y estoy agradecido por ella y espero que no esté obsoleta, sino que reviva.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/request/request/issues/3142#issuecomment-482043697 , o silencie el hilo https://github.com/notifications/unsubscribe-auth/AAACQ8I4BSRtOjqHk637gRfBhkvGbRw4Iksga .

Los paquetes de TIL 41k se volvieron vulnerables.

Mire, estoy de acuerdo en que la solicitud debería desaparecer, pero siempre tengo miedo de que paquetes convencionales como este cambien su canal de lanzamiento. Un mal actor o una caja de desarrollo comprometida que publique código malicioso se propagaría efectivamente a todos los proyectos que existen.

Considere ajustar los requisitos de empuje de npm. Configure una sucursal para ci, requiera múltiples aprobaciones, algo más que simplemente presionar para dominar.

aunque sin promesas.

¿Juego de palabras? 🤣

¿Quizás el mismo razonamiento lógico debería aplicarse a expressjs? por solicitud, ahora tenemos el nuevo módulo shiny got, no hay ninguna reescritura o una verdadera alternativa a expressjs en el horizonte.

express es genial, pero en realidad no se actualiza activamente con nuevas funciones en estos años.

Es posible que express no se actualice con nuevas funciones, pero se mantiene de forma activa y, la última vez que lo comprobé, algunas personas todavía están bastante interesadas en hacer ese trabajo. No sé si deben tomar las medidas que hemos tomado para su desaprobación.

@laoshaw, ¿qué tiene que ver express con request ?

Preparando la desaprobación total. https://github.com/request/request/pull/3267

¡Estamos totalmente obsoletos!

Todas las versiones en npm notan la desaprobación y el README señala claramente que request ha quedado obsoleto.

Han sido más de 10 años maravillosos, gracias a todos los que contribuyeron durante la última década. Esperemos con ansias las nuevas bibliotecas que se adapten mejor a los cambios que se están produciendo en el lenguaje y el ecosistema JS.

Así que seamos ESPECÍFICOS.
¿Cuál es el reemplazo del código Lean para el módulo de solicitud?

Para no quedarse colgando de la corteza muerta ... tantas opciones mejores ... ¿como CUÁLES?
No GRAND haga todo bajo las bibliotecas / módulos del sol, por favor.

@riclf , hemos estado usando https://github.com/googleapis/teeny-request/ para ayudarnos a evitar la solicitud durante algunos años. No hace todo lo que quieres que haga :) Utiliza node-fetch bajo el capó. ¡También hay otras opciones geniales!

Para una solución de promesa primero, también hay gofer que se centra en gran medida en la comunicación API. Soporte para tiempos de espera de conexión TCP incorporados, configuración fácil (y errores enriquecidos) para hablar con múltiples API, etc.

¿Alguien tiene alguna recomendación para clientes alternativos que tengan un buen soporte para HTTP Long Polling y se presenten como Stream o Event Emitter?

La última vez que verifiqué en abril de 2019, alternativas como got , node-fetch y axios tenían un problema importante: cuando ocurrió un error (de red de bajo nivel), descartaron el útil seguimiento de pila informado por el núcleo de Node.js y arrojó un nuevo error de alto nivel con un seguimiento de pila que apunta a la biblioteca cliente http solamente. Esto hizo que la depuración de problemas a nivel de transporte fuera prácticamente imposible, por ejemplo, cuando se trata de proxies.

¿Existe alguna buena alternativa request que conserve los detalles del error proporcionados por el núcleo de Node.js?

@bajtos Estoy bastante seguro de que gofer solo decora los errores originales, pero debería preservar los rastros y mensajes de la pila.

bent tiene errores agradables y está diseñado para async / await. También es increíblemente pequeño y el tamaño del paquete es diminuto;)

Sin embargo, la API no se parece en nada a una solicitud, por lo que no la llamaría un "reemplazo".

@mikeal ¿ bent ? (La solicitud era un nombre más fácil de recordar).

bent tiene errores agradables y está diseñado para async / await. También es increíblemente pequeño y el tamaño del paquete es diminuto;)

Sin embargo, la API no se parece en nada a una solicitud, por lo que no la llamaría un "reemplazo".

Esto se parece mucho a una lógica técnicamente correcta en lugar de fácil de usar. Desde la perspectiva del usuario, bent resuelve el mismo problema que la solicitud, pero mejor. Ahora tiene un nombre peor sin motivo. Puede llamarlo solicitud 3 sin mucho problema en mi opinión. Sí, la API se está rompiendo, pero para qué tenemos semver.

Puede llamarlo solicitud 3 sin mucho problema en mi opinión. Sí, la API se está rompiendo, pero para qué tenemos semver.

Pase algún tiempo con bent y puede que se sienta diferente.

No es una pequeña diferencia entre los nombres o las promesas y las devoluciones de llamada. La ergonomía es muy diferente, los estados en los que aparece son muy diferentes, la forma en que piensa sobre las condiciones de error es un enfoque radicalmente diferente.

request es una API más procedimental, le dices que haga algo y te dice lo que sucedió, solo da un error si algo falla irremediablemente. bent toma los criterios de éxito para todo el ciclo de vida y le devuelve una API que fallará si se cumple algo que no

Usas estas bibliotecas de manera muy diferente. Hay otras bibliotecas que están más cerca de la API de request si eso es lo que desea, pero después de casi 20 años de trabajar en clientes HTTP, encontré un enfoque diferente y, en última instancia, mejor que animaría a la gente. para considerar, pero no voy a apisonarlo a todos haciéndolo request 3.0.

¿Por qué se llama doblado? (La solicitud era un nombre más fácil de recordar).

Porque lo "dobla" en una forma específica (criterio de éxito muy particular) y proporciona una API ideal para el éxito de esa forma y falla en cualquier cosa menos en ella.

El nombre es un poco abstracto, pero request es el tipo de nombre que nunca podría obtener hoy. Apenas obtuve request en el registro npm y escribí el registro npm original 😜

¿Qué pasa con "got" como reemplazo, es triste que no tengamos un reemplazo claro mientras que la solicitud está oficialmente obsoleta?

¿Qué pasa con "got" como reemplazo, es triste que no tengamos un reemplazo claro mientras que la solicitud está oficialmente obsoleta?

Tal vez deberíamos tomar el hecho de que nadie ha escrito un reemplazo compatible con API como una indicación de que adoptar un reemplazo compatible con API no es deseable una vez que se sienta y trabaja en él 🧐

Sin duda esa fue mi experiencia.

Quizás lo que la gente realmente quiere cuando pide un "reemplazo", no es tanto una alternativa compatible con API, sino la perspectiva del mantenedor sobre qué otros paquetes ya existen para resolver aproximadamente el mismo problema y que hacen que este paquete sea irrelevante, por lo que con seguridad puede llamarlo "obsoleto".

Y yo diría que anunciar bent en el aviso de desaprobación (posiblemente junto con algunos otros, si eso lo hace sentir más cómodo) es una excelente manera de comenzar a darlo a conocer a pesar del nombre oscuro.


Módulo de solicitud de Angluar 8 en desuso

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

¿Entiendes realmente lo que realmente significa "obsoleto"?

Obsoleto. En el mundo del desarrollo de software, "obsoleto" se refiere a funciones o elementos que están en proceso de ser reemplazados por otros más nuevos. El término proviene de la palabra "desaprobar", que significa desaprobar algo.

En la práctica, esto significa que cuando mantengo alguno de mis módulos (que no son de código abierto), recibiré mensajes de error tontos.

¿Qué pasa con los 151 problemas y las 55 solicitudes de extracción? ¿Desecharlos?

Y yo diría que la publicidad doblada en el aviso de desaprobación (posiblemente con otros si eso lo hace sentir más cómodo) es una excelente manera de comenzar a darlo a conocer, a pesar del nombre oscuro.

Esto es DEMASIADO pronto; consulte el número 2 de bent.

Creo que la solicitud debe entrar en un modo limbo, no desaprobado, lo que causa advertencias tontas, pero donde NADA se realizará, se ignorarán todos los problemas y extracciones y la página README debe actualizarse para tener en cuenta esto y, cuando corresponda, se harán referencias. incluido en otros paquetes funcionalmente equivalentes.

¿Qué pasa con los 151 problemas y las 55 solicitudes de extracción? ¿Desecharlos?

Nadie ha sido la fijación o revisión de éstos durante algún tiempo, que ya eran “objeto de dumping”.

Sus comentarios hacen que parezca que hay algún tipo de trabajo dedicado en este proyecto al que la gente tiene derecho. Este nunca ha sido el caso, request no es un producto lanzado y respaldado por una empresa, siempre ha sido mantenido por desarrolladores de código abierto que se preocupan y, a medida que el ecosistema se ha movido en una nueva dirección, todos nos movimos con él. . Te recomiendo que sigas adelante también.

Nadie los ha estado arreglando o revisando durante algún tiempo, ya estaban "descartados".

Lo que quiere decir es que USTED no los ha estado revisando por algún tiempo. Seamos justos, los que no somos colaboradores no tenemos control sobre esto.

Sus comentarios hacen que parezca que hay algún tipo de trabajo dedicado en este proyecto al que la gente tiene derecho.

No quise decirlo así, pero en cierto sentido es cierto, el software de código abierto otorga ciertos derechos al usuario además de proteger los derechos del desarrollador. Estos derechos son de uso, no de mantenimiento. Cuando el mantenimiento o el desarrollo posterior implican cambios importantes, se debe tener mucho cuidado y pensar. Este es un cambio rotundo y, en mi opinión, innecesario. Simplemente deje el módulo como está y todos pasaremos al siguiente proyecto, especialmente si la alternativa ofrece ventajas. De hecho, sería una tontería no hacerlo. Pero por lo que puedo ver, por el momento no existe una alternativa real.

El software de código abierto otorga ciertos derechos al usuario

Las licencias de OSS otorgan derechos para redistribuir y modificar, no se ofrecen garantías de ningún tipo sobre la idoneidad del software para un uso en particular. Nunca se ofrecen garantías sobre cambios futuros, incluidos los posibles cambios importantes.

Aquí está el texto relevante de la licencia de Apache 2. Casi todas las licencias de código abierto tienen esto.

“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.”

Este es un cambio rotundo y, en mi opinión, innecesario. Simplemente deje el módulo como está y todos pasaremos al siguiente proyecto, especialmente si la alternativa ofrece ventajas. De hecho, sería una tontería no hacerlo. Pero por lo que puedo ver, por el momento no existe una alternativa real.

Aquí está la cosa. Este código tiene errores conocidos que no se solucionarán. Este código ya no se mantiene y está obsoleto.

La advertencia de desaprobación es un aviso de que está confiando en un código problemático. Si está bien confiando en un código obsoleto y problemático, simplemente suprima los mensajes. Su problema parece ser las advertencias y no el estado del software. Si está de acuerdo con el estado del software, simplemente elimine las advertencias.

No modificaremos el estado de obsolescencia y las advertencias relevantes para que no estén en línea con la realidad a fin de satisfacer la preocupación de cualquier usuario en particular sobre las advertencias que pueden suprimir fácilmente si no les preocupa depender de módulos obsoletos.

necesito ayuda !!! .. estoy teniendo estos problemas cuando intento instalar node-gyp 3.6.2
PS C: \ Usuarios \ Usuario> npm install --global [email protected]
npm WARN obsoleto [email protected] : la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142
npm ERR! ruta C: \ Users \ User \ AppData \ Roamingnpm \ node-gyp.cmd
npm ERR! código EEXIST
npm ERR! Negarse a eliminar C: \ Users \ User \ AppData \ Roamingnpm \ node-gyp.cmd: está fuera de C: \ Users \ User \ AppData \ Roamingnpm \ node_modules \ node-gyp y no un enlace
npm ERR! El archivo existe: C: \ Users \ User \ AppData \ Roamingnpm \ node-gyp.cmd
npm ERR! Aléjelo y vuelva a intentarlo.

npm ERR! Puede encontrar un registro completo de esta ejecución en:
npm ERR! C: \ Users \ User \ AppData \ Roamingnpm-cache_logs \ 2020-02-13T05_12_13_683Z-debug.log

@mikeal Oh, este es un caso interesante. Tener el número de problema en el aviso de desaprobación puede traer muchos comentarios no relacionados aquí, como demostró @Meharab .

¿Quizás es hora de evitar más comentarios aquí?

ACTUALIZACIÓN : 5 días después y los comentarios se están acumulando.

@mikeal Gracias por estos años

Solicitud de buenas noches. Nos vemos en el otro lado.

la solicitud va a funcionar para siempre (como está), porque eso es JavaScript ... bueno, a menos que Node introduzca un cambio rotundo al desaprobar una API central utilizada por él

la solicitud va a funcionar para siempre (como está), porque eso es JavaScript ... bueno, a menos que Node introduzca un cambio rotundo al desaprobar una API central utilizada por él

No.
Este código tiene errores conocidos que no se solucionarán. Este código ya no se mantiene y está obsoleto. (cit.)

Entonces, la solicitud tendrá errores sin corregir para siempre, no funcionará para siempre ...

No lo entiendo. Entonces, ¿qué se supone que debo hacer oficialmente ahora, para no recibir la advertencia de desaprobación?

Quitar request . Esto puede implicar eliminarlo de sus propias dependencias, actualizar paquetes que lo eliminan en versiones más recientes o eliminar paquetes que aún no se han actualizado con versiones más nuevas.

Hola.

Estoy intentando instalar cordova.

npm install -g cordova

sigo recibiendo este error.
Microsoft Windows [Versión 10.0.18362.592]
(c) 2019 Microsoft Corporation. Reservados todos los derechos.

C: \ Usuarios> npm install -g cordova
npm WARN obsoleto [email protected]: la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142
C: \ Users \ AppData \ Roamingnpm \ cordova -> C: \ Users \ AppData \ Roamingnpm \ node_modules \ cordova \ bin \ cordova

¿Hay otra forma de instalar Cordova?
¿Una forma de evitar esta compra?

Si. Está bien. Eliminaré la solicitud. ¿Pero entonces qué?

Entonces, en node.js tengo que cambiar a .. idk .. axios?

¿Qué se supone que debo poner en el lugar de reqest?

Entiendo que la idea es reescribir todas las funciones donde la solicitud estaba presente.

¿Hay algún paquete que pueda cambiar con buscar y reemplazar con expresiones regulares?

¿Existe un reemplazo oficial para la solicitud o simplemente estamos libres ahora para encontrar lo que aparezca primero en Google? No lo entiendo

¿Existe un reemplazo oficial para la solicitud?

No, puedes usar lo que quieras, aunque el mismo desarrollador está trabajando en bent

También está la bifurcación postman-request que ha recibido varias correcciones, ~ pero no ha tenido ninguna actividad desde la desaprobación de request . ~

Como no tienen una página de problemas, supongo que intentaré preguntar aquí:

@coditva @codenirvana @shamasis @vikiCoder @czardoz

Disculpas por las menciones, pero ¿cuáles son los planes para el futuro de postman-request ahora que request está oficialmente muerto? ¿Se mantendrá postman-request o también quedará obsoleto?

¡¡¡necesitas ayuda!!! Estoy intentando instalar angular, tengo un problema
npm install -g @ angular / cli
npm WARN obsoleto [email protected]: la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142
npm ERR! código EEXIST
npm ERR! ruta C: \ Users \ FARHAN \ AppData \ Roamingnpm \ node_modules \ @angular \ cli \ bin \ ng
npm ERR! dest C: \ Users \ FARHAN \ AppData \ Roamingnpm \ ng.cmd
npm ERR! EEXIST: el archivo ya existe, cmd shim 'C: \ Users \ FARHAN \ AppData \ Roamingnpm \ node_modules \ @angular \ cli \ bin \ ng' -> 'C: \ Users \ FARHAN \ AppData \ Roamingnpm \ ng.cmd'
npm ERR! El archivo existe: C: \ Users \ FARHAN \ AppData \ Roamingnpm \ ng.cmd
npm ERR! Elimine el archivo existente e intente nuevamente, o ejecute npm
npm ERR! con --force para sobrescribir archivos de forma imprudente.

npm ERR! Puede encontrar un registro completo de esta ejecución en:
npm ERR! C: \ Users \ FARHAN \ AppData \ Roamingnpm-cache_logs \ 2020-02-15T09_52_19_067Z-debug.log

¿Cuáles son las alternativas a request ? Angular todavía depende de él. Espero que estén actualizando su código base pronto.

Tengo una solución a corto plazo a la que Mikeal Rogers retrocederá, tal vez incluso me atacará. Esta desaprobación actual se produjo en 2 fases no programadas: 1) una Discusión general de su necesidad, 2) BANG, con un aviso de aproximadamente 30 minutos y se implementó. Todo el infierno se ha desatado.

Le pregunto a @mikeal si consideraría revertir la depreciación hoy y anunciar un "Aviso de depreciación" de 6 meses, que se implementará y se efectuará por completo el 15 de agosto de 2020.

Las 3 fases
1) Discusión: 20 de marzo de 2019 al 15 de febrero de 2020
2) Aviso de cancelación de 6 meses: 15 de febrero de 2020
3) Implementación de la desactivación: 15 de agosto de 2020

De esta manera, no solo los marcos y los proyectos de aplicación NO se rompen instantáneamente, lo cual es demasiado duro, sino que esta comunidad ahora puede usar ESTA área de discusión para compartir alternativas, los +/- durante los próximos meses y poner las alternativas en su lugar. antes de la fecha límite de 6 meses. Luego, cuando suceda, todos podemos saludarlo, gritar cheerio y no se rompe nada.

Por favor, comprenda, no estoy argumentando sobre la necesidad de su desaprobación, o el derecho del creador a hacerlo ... Estoy sugiriendo un programa de notificación previa de 3 pasos, como se indicó anteriormente, que explicará su uso significativo en la comunidad de desarrolladores y las aplicaciones vivas en el mundo hoy en día, según el módulo de solicitud.

Mikeal, por favor, considere mi sugerencia, elimine el estado de Desactivación hoy y anuncie el aviso de 6 meses. Menos de 6 meses no es tiempo suficiente para muchos de nosotros, 6 es justo. Te lo agradecería, todos lo haríamos.

Muchas gracias por escucharme
-Ric Fink

Sin embargo, agregar una advertencia de desaprobación no rompe nada, solo advierte a los usuarios que podría romperse en el futuro. Prefiero ver un mensaje de desaprobación antes que tener que esperar la discusión de la comunidad antes de saber que eventualmente tendré que reemplazar un paquete.

Además, un recordatorio amistoso de que este paquete se estaba desarrollando a través de código abierto de forma gratuita, y el encargado de mantenimiento no le debe nada. Si desea continuar usando el paquete, puede bifurcarlo y continuar manteniéndolo usted mismo.

@riclf

¡¡¡necesitas ayuda!!! Estoy intentando instalar angular, tengo un problema
npm install -g @ angular / cli
npm WARN obsoleto [email protected]: la solicitud ha quedado obsoleta, consulte # 3142
npm ERR! código EEXIST
npm ERR! ruta C: \ Users \ FARHAN \ AppData \ Roamingnpm \ node_modules @ angular \ cli \ bin \ ng
npm ERR! dest C: \ Users \ FARHAN \ AppData \ Roamingnpm \ ng.cmd
npm ERR! EEXIST: el archivo ya existe, cmd shim 'C: \ Users \ FARHAN \ AppData \ Roamingnpm \ node_modules @ angular \ cli \ bin \ ng' -> 'C: \ Users \ FARHAN \ AppData \ Roamingnpm \ ng.cmd'
npm ERR! El archivo existe: C: \ Users \ FARHAN \ AppData \ Roamingnpm \ ng.cmd
npm ERR! Elimine el archivo existente e intente nuevamente, o ejecute npm
npm ERR! con --force para sobrescribir archivos de forma imprudente.

npm ERR! Puede encontrar un registro completo de esta ejecución en:
npm ERR! C: \ Users \ FARHAN \ AppData \ Roamingnpm-cache_logs \ 2020-02-15T09_52_19_067Z-debug.log

Esto parece haber sido resuelto por la última versión de Angular en la que request se reemplaza con node-fetch .

@AURZeeshan
Su error no se relaciona con esto. Solo está viendo una advertencia de este paquete, el error es diferente.

@riclf

¡¡¡necesitas ayuda!!! Estoy intentando instalar angular, tengo un problema
npm install -g @ angular / cli
npm WARN obsoleto [email protected]: la solicitud ha quedado obsoleta, consulte # 3142
npm ERR! código EEXIST
npm ERR! ruta C: \ Users \ FARHAN \ AppData \ Roamingnpm \ node_modules @ angular \ cli \ bin \ ng
npm ERR! dest C: \ Users \ FARHAN \ AppData \ Roamingnpm \ ng.cmd
npm ERR! EEXIST: el archivo ya existe, cmd shim 'C: \ Users \ FARHAN \ AppData \ Roamingnpm \ node_modules @ angular \ cli \ bin \ ng' -> 'C: \ Users \ FARHAN \ AppData \ Roamingnpm \ ng.cmd'
npm ERR! El archivo existe: C: \ Users \ FARHAN \ AppData \ Roamingnpm \ ng.cmd
npm ERR! Elimine el archivo existente e intente nuevamente, o ejecute npm
npm ERR! con --force para sobrescribir archivos de forma imprudente.
npm ERR! Puede encontrar un registro completo de esta ejecución en:
npm ERR! C: \ Users \ FARHAN \ AppData \ Roamingnpm-cache_logs \ 2020-02-15T09_52_19_067Z-debug.log

Esto parece haber sido resuelto por la última versión de Angular en la que request se reemplaza con node-fetch .

Instalé la última versión de CLI. Todavía lanza la misma advertencia

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

@ vighnesh153 ¿Qué versión de @angular/cli se especifica en su package.json? Parece que algunas de las dependencias necesitan una solicitud, pero no el paquete base en sí. Ver http://npm.anvaka.com/#/view/2d/% 2540angular% 252Fcli

Quizás tengas razón. No estoy muy seguro de cuál de los paquetes está utilizando el paquete de solicitud. Aquí hay un chasquido de los deps:

"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 obsoleto [email protected] : la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142

cuando quiero completar "npm install" en \ vue-devtools-dev, he advertido sobre esto
Cómo puedo resolverlo ?

Respeto totalmente su decisión de desaprobarla y le deseo lo mejor para el futuro.

En cuanto a las personas que llegan al hilo en busca de "entonces, ¿qué debo usar a partir de ahora?", got o axios son lo que estás buscando.

Patético. Es hora de migrar a la búsqueda de nodos.

... excepto que usted mismo se pregunta si node-fetch es un buen reemplazo para request , o incluso si se mantiene activamente. Ciertamente patético.

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

Por cierto, las personas que optan por node-fetch realmente deben tener cuidado. Esa biblioteca, aunque excelente, tiene graves problemas de mantenimiento.

Patético. Es hora de migrar a la búsqueda de nodos.

... excepto que usted mismo se pregunta si node-fetch es un buen reemplazo para request , o incluso si se mantiene activamente. Ciertamente patético.

node-fetch / node-fetch # 668 (comentario)

Al menos la recuperación de nodos no está en desuso. La desaprobación total de la solicitud ha causado problemas con los sistemas de compilación automática. No entiendo y no acepto este movimiento y, en mi opinión, una simple nota explicando que la biblioteca no está mantenida sería suficiente en lugar de una fuerte desaprobación. Por eso considero patética esta situación.

en mi opinión, una simple nota explicando que la biblioteca no se mantiene sería suficiente

Eso es exactamente lo que es un aviso de desaprobación: una simple nota.

@asgetz todo lo que hace npm es imprimir esa advertencia al instalar un paquete obsoleto, todo lo demás funciona exactamente como antes.

Tengo problemas con los archivos less.js que funcionan en github. Funcionan bien dentro de PHP. Cuando intenté poner menos en el comando, apareció esta advertencia. ¿Alguna idea sobre cuál es el problema?

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

La solicitud de

¿Hay un reemplazo para request , pero con la interfaz de transmisión de node.js? Encontré que node-fetch , axios se basan en Promise .

Me gustaría saber un reemplazo para la interfaz de transmisión, que es más conveniente para casos de uso de nivel inferior.

@ maple3142 got tiene una interfaz de transmisión (así como promesas) y una guía de migración .

@asgetz

npm me indica que tengo que instalarlo yo mismo ahora.

¿De qué manera está indicando eso? Cuando instalo request , recibo el aviso de desactivación y todo funciona como antes.

mi uso planeado es tan pequeño

En ese caso, tal vez eche un vistazo a Bent, que es mucho más liviano y parece funcionar bien.

@mikeal , ¿puedes echar un vistazo a https://github.com/request/request/pull/3245? proxyHeaderExclusiveList es una de las mejores características de este paquete y no funciona correctamente.
¡Arreglemos esto!

@kauegimenes este paquete está en desuso ... nada se arreglará nunca más

@kevinvanrijn Ya no estoy involucrado activamente en el mantenimiento de postman-request , pero el proyecto definitivamente está vivo y el último lanzamiento fue hace un mes. Sin embargo, dejaré que los mantenedores activos intervengan en los planes a más largo plazo.

@czardoz Es bueno saberlo. Tengo un montón de proyectos pequeños (todos privados) dependiendo de request que no puedo dedicar tiempo a reescribir. Dejar caer postman-request como reemplazo significa que puedo confiar en que continuarán funcionando por un poco más de tiempo.

cloudscraper también está sufriendo un mantenimiento lento y es probable que todavía no pueda alejarse de request . Tener postman-request disponible como opción significa que al menos no correrá el riesgo de quedar obsoleto.

@ Edo78 ¿por qué dices eso? todavía tengo fe un día mi PR se fusionará 😆

Los confirmadores que aún están activos intentarán fusionar las correcciones de manera oportuna, aunque sin promesas.

Por cierto, las personas que optan por la búsqueda de nodos realmente deben tener cuidado. Esa biblioteca, aunque excelente, tiene graves problemas de mantenimiento.

@csvan ¿Puedes explicar un poco? Solo veo algunos problemas

Sé muy poco sobre npm. Lo usé para instalar una API y recibí algunas advertencias que no entiendo. Me dirigen aquí. Esto es totalmente inútil para mí. Alguien debería publicar algo aquí que sea útil para aquellos de nosotros dirigidos aquí o el mensaje en npm debería arreglarse para que sea más útil. Los siguientes son los mensajes que recibí.

npm WARN obsoleto [email protected] : la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142
npm WARN saveError ENOENT: no existe tal archivo o directorio, abra 'C: \ Users \ Sam \ package.json'
npm notice creó un archivo de bloqueo como package-lock.json. Debe enviar este archivo.
npm WARN enoent ENOENT: no existe tal archivo o directorio, abra 'C: \ Users \ Sam \ package.json'
npm WARN Sam Sin descripción
npm WARN Sam Sin campo de repositorio.
npm WARN Sam No hay datos README
npm WARN Sam Sin campo de licencia.

Además, no hay un archivo package.json pero hay un package-lock.json. No tengo ni idea de qué buscar allí.

@SimpleSamples el paquete está en desuso y no se mantendrá activamente aparte de posibles correcciones de errores, como se explica claramente en el texto. NPM simplemente le advierte que está utilizando un paquete obsoleto, para que tenga la oportunidad de cambiar a otra cosa.

Si no comprende lo que significa la obsolescencia, hay varios artículos útiles a una búsqueda de Google.

Sí, entiendo lo que significa la desaprobación y, por lo tanto, el enlace al
La discusión del Pasado, Presente y Futuro de la Solicitud no proporciona ninguna
aclaración, solo agrega confusión. ¿O hay algo más que hago?
no entiendes y no estas aclarando? Si solo dice eso
La solicitud está obsoleta, entonces eso es todo lo que necesita decir, en lugar de
lo que implica que hay algo más que debemos hacer.

Sería de gran ayuda si dijera (enlace a un artículo
explicando) qué lo reemplaza, o cualquier acción de la que debamos ser conscientes.

Christopher Svanefalk [email protected]
Martes, 18 de febrero de 2020 22:45

@SimpleSamples https://github.com/SimpleSamples el paquete es
obsoleto y no recibirá más actualizaciones, ya que el texto
explica claramente. NPM simplemente le advierte que está utilizando un
paquete obsoleto.

Si no comprende lo que significa la desaprobación, hay varios
artículos útiles a una búsqueda de Google.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/request/request/issues/3142?email_source=notifications&email_token=ACK22R4G7LHULMPO6DHH273RDTIP7A5CNFSM4HCP6LRKYY3PNVWWK3TUL52HS4DFVREXH63JSMVBW5 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/ACK22R7UFQSYKW7NEYZ4OTDRDTIP7ANCNFSM4HCP6LRA .

Si solo dice que la solicitud está obsoleta, eso es todo lo que necesita decir

Sí, que se joda a cualquiera que aprecie el contexto y le guste saber las razones de las decisiones o que quiera conocer los detalles sobre la eliminación. :PAG
Sin embargo, para ser serio, si se hubiera agregado un "por qué" a la advertencia, ¿eso habría evitado su confusión?

"npm WARN obsoleto [email protected] : la solicitud ha quedado obsoleta, consulte el # 3142 para saber

Tienes razón. No vi la parte de "por qué".

Espen escribió:

"como qué"

@SimpleSamples lo siento si no entiendo bien, pero realmente no veo la confusión. La solicitud está obsoleta y el texto de este número explica con bastante claridad por qué y qué implica.

¿De dónde sacas la idea de que necesitas hacer algo? Una desaprobación es solo una desaprobación, la forma en que la maneje depende de usted.

No hay nada de malo en los usos de la solicitud de patrones. Por el contrario, existe una gran comunidad en el ecosistema de JavaScript que todavía utiliza estos patrones. En mi experiencia, es una comunidad mucho más grande que la minoría vocal (la mayoría de las grandes empresas) que tienen los recursos para romper constantemente bases de código que funcionan perfectamente por nada más que la vanidad y la arrogancia de los desarrolladores.

Lamento que hayas caído en esta trampa, la solicitud ha sido un gran servicio a la comunidad y espero sinceramente que reconsideres tu decisión.

Sí, me entristece que esto se haya ido. Las devoluciones de llamada no son malas, ni las promesas ni la asincronización en espera.

Creo que lo que te estás perdiendo @SimpleSamples es que el resto de las advertencias que pegaste no tienen nada que ver con la advertencia de desaprobación que te trajo aquí. No necesita hacer nada con respecto a la desaprobación, pero es posible que desee hacer algo con respecto a su package.json faltante (o lo que sea que esté causando esas otras advertencias).

Entonces, ¿qué se supone que debemos hacer ahora con todos esos paquetes que están usando request bajo el capó?

Intenté reemplazar request con @root/request en uno de esos paquetes, asumiendo que de hecho era un reemplazo directo, pero no pude hacer que funcionara .

También intenté reemplazar request con algo como ...

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

... y...

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

... pero tampoco pude hacer que eso funcionara.

¿Y ahora que? En ausencia de un reemplazo directo que realmente cumpla su promesa, ¿se supone que todos debemos vivir con múltiples dependencias en nuestro node_modules que dependen de un paquete obsoleto, varios de los cuales no parecen funcionar? ¿ser mantenido? ¿Y por qué?

Entiendo que request ha quedado desactualizado en varios aspectos, pero al desaprobar este paquete sin ofrecer un reemplazo directo adecuado, los módulos de 41K ahora dependen directamente de un paquete obsoleto. Si consideramos los paquetes que usan al menos uno de estos módulos de 41K como una dependencia, podemos estar hablando de cientos de miles, si no millones, de paquetes afectados.

Claro, supongo que para algunos paquetes, es fácil reemplazar request con algo como fetch , axios , superagent o http.request nativo de Node.js https.request . Pero por ejemplo. en el caso de que las solicitudes se envíen a otra solicitud (como con html2canvas-proxy ), me cuesta averiguar qué diablos está pasando allí ... y realmente no puedo permitirme pasar muchas horas tratando de reemplazar solo unas pocas líneas de código obsoleto, mientras que en realidad debería estar haciendo cosas más importantes.

Siempre he estado cansado de depender demasiado de una multitud de paquetes interdependientes que se cargan en segundo plano con un administrador de paquetes. Sí, supongo que puede descargar gran parte del trabajo pesado a terceros, pero en su lugar, tienes un montón de otros dolores de cabeza con los que lidiar.

Los administradores de paquetes nos dan una falsa sensación de seguridad. Toda la debacle del leftpad de hace 4 años parece no haber abierto los ojos a la gente con respecto a los riesgos involucrados. Estoy seguro de que esto tampoco hará ninguna diferencia. Aún así, siento que debo enfatizar que hay algo muy mal cuando un paquete obsoleto o roto puede afectar a millones de paquetes en todo el ecosistema. Y es probable que esto solo empeore, ya que más y más proyectos serán abandonados, obsoletos o incluso rotos a medida que pase el tiempo, y todos estaremos viviendo en el infierno de la dependencia ...

Pero bueno ... supongo que al menos eso significa que siempre habrá una demanda para que los desarrolladores de JS limpien el desorden $% # @ ...

@jslegers

Aún así, siento que debo enfatizar que hay algo muy mal cuando un paquete obsoleto o roto puede afectar a millones de paquetes en todo el ecosistema.

Lo único que está mal es el pánico que usted y los demás parecen estar sufriendo. leftpad desapareció, se eliminó. Eso no puede suceder ahora. La solicitud simplemente ha quedado obsoleta; no va a ninguna parte. Si funciona ahora, seguirá funcionando de la misma forma.

No hay impacto en millones de paquetes, a menos que cuente con una advertencia benigna.

También intenté reemplazar la solicitud con algo como ...

Por favor deje de entrar en pánico; deje de intentar solucionar un problema que no existe. Use los paquetes que desee: la desaprobación de la solicitud no los romperá. Gradualmente, sus encargados de mantenimiento de paquetes pueden cambiar a otro paquete. O puede que no. No importa. Nada ha cambiado, salvo la apariencia de un pequeño mensaje.

siempre habrá una demanda para que los desarrolladores de JS limpien el desorden $% # @ ...

No hay lío. Solo progreso.

No hay impacto en millones de paquetes, a menos que cuente con una advertencia benigna .

Depredador, por ejemplo. una parte de su API o una biblioteca básicamente significa que la designa oficialmente como "obsoleta" y anima activamente a los usuarios a optar por otra cosa.

La obsolescencia se usa normalmente como una etapa intermedia entre el soporte oficial de algo y el abandono oficial del soporte para algo, para darles a los desarrolladores el tiempo de reemplazar lo que sea que hayas desaprobado hasta que ya no esté disponible o sea compatible con versiones anteriores.

Se supone que las advertencias de obsolescencia te ponen nervioso. Están pensados ​​como una llamada a la acción. Básicamente, el punto de desaprobación es ofrecer a los desarrolladores un "período de gracia", permitiéndoles actualizar su código antes de que alguien lo desconecte.

Y no deben usarse para ningún otro propósito. No se supone que la obsolescencia solo informe a sus usuarios que "Nuestra API no sigue los últimos estándares de codificación" o "Ya no tengo tiempo para mantener este proyecto" ... aunque la biblioteca es bastante estable y bonita seguro de usar en + 99% de todos los casos de uso y es probable que continúe funcionando bien durante al menos la próxima década más o menos. Eso no es lo que significa la desaprobación, y el uso de advertencias de desaprobación solo para expresar un mensaje como ese sienta un precedente muy malo, en mi opinión.

Además, es simplemente feo tener sus registros de npm install llenos de advertencias de depreciación. Parece descuidado. Es una especie de bandera roja y crea una mala primera impresión para las personas que prueban su biblioteca o marco. Especialmente si la gente realmente le paga por usar su biblioteca / marco, desea brindarles un proceso de instalación agradable / limpio sin advertencias.

Nada ha cambiado, salvo la apariencia de un pequeño mensaje.

Ese pequeño mensaje parece descuidado y se supone que no tiene otro propósito que un llamado a la acción ... un llamado a reemplazar un paquete obsoleto con otra cosa.

Puede que eso no te importe, pero definitivamente me importa a mí y a otras personas.

No hay lío. Solo progreso.

Supongo que eres una de esas personas que no pueden diferenciar entre cambio y progreso.

De cualquier manera, noté que otros en los comentarios sugirieron usar postman-request . A diferencia de @root/request , ese parece funcionar como un reemplazo directo, así que actualizaré todos mis paquetes con este por el momento ...

Creo que lo que te estás perdiendo @SimpleSamples es que el resto de las advertencias que pegaste no tienen nada que ver con la advertencia de desaprobación que te trajo aquí. No necesita hacer nada con respecto a la desaprobación, pero es posible que desee hacer algo con respecto a su package.json faltante (o lo que sea que esté causando esas otras advertencias).

Touché!

Se ha hecho hincapié, pero los ataques personales continúan. Ustedes son muy inteligentes y altamente capacitados técnicamente, pero hay margen de mejora en la experiencia personal.

Se ha hecho hincapié, pero los ataques personales continúan. Ustedes son muy inteligentes y altamente capacitados técnicamente, pero hay margen de mejora en la experiencia personal.

Desafortunadamente, ser inteligente no evita que las personas dejen que sus emociones enturbien sus juicios ... especialmente cuando sus cosas suceden como cosas que se desaprueban aparentemente sin una buena razón o un consenso general sobre cuál es el propósito de la desaprobación.

De todos modos, creo que dejé mi punto con bastante claridad. Me gustaría terminar animando a @mikeal , @reconbot o cualquier otro mantenedor de este proyecto a proponer oficialmente postman-request como un reemplazo directo de funciones completas para request , y posiblemente @root/request para aquellos que solo necesitan un subconjunto limitado de request y no les importa, por ejemplo. arroyos. Esto permite que cualquier mantenedor de paquetes descarte request y se deshaga del molesto mensaje de desaprobación sin gastar más de unos minutos de tiempo de desarrollo en este problema, y ​​sin tener que refactorizar toda su biblioteca o aplicación.

@mikeal a raíz de la realidad de que la solicitud está desaprobada, me gustaría pedirle un momento de reflexión que será útil para algunos o tal vez para muchos de nosotros. Tiene 2 módulos de solicitud http posteriores, posteriores a la solicitud: r2 y bent.

¿Puedo pedirle que nos brinde un breve resumen de las diferencias, los beneficios y los más o menos de mudarse a uno de los reemplazos de solicitud, sobre el otro? Confío en tu trabajo.

Gracias por este tiempo y puedo estar seguro de agradecerles por los años del módulo de solicitud.

-Ric

¿ request-promise-native también está obsoleto o es lo correcto para usar?

[email protected] : la solicitud se ha duplicado ... no se puede crear un nuevo proyecto

[email protected] : la solicitud se ha duplicado ... no se puede crear un nuevo proyecto

Puede crear un proyecto como siempre. NPM simplemente le está dando una advertencia.

¿Por qué se ha eliminado este proyecto?

si esto está bien

Utilizado por 4,476,352 repositorios, 52,377 paquetes.
Dile adiós a la leyenda.

¿Por qué se ha eliminado este proyecto?

@jleppert no lo ha hecho, lea el problema que está comentando.

Intenté instalar angular en linux y luego en windows y en ambos no pude, luego de ejecutar el comando npm install -g @ angular / cli @ latest en ambos me apareció este error

C: \ Users \ Hanzell> npm install -g @ angular / cli @ latest
npm WARN obsoleto [email protected]: la solicitud ha quedado obsoleta, 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

Luego, creé el repositorio y apareció este

C: \ Users \ Hanzell \ Desktop> ng nuevo
? ¿Qué nombre le gustaría usar para el nuevo espacio de trabajo y el proyecto inicial? Hola
? ¿Le gustaría agregar enrutamiento angular? No
? ¿Qué formato de hoja de estilo le gustaría utilizar? CSS
CREAR hola / angular.json (3551 bytes)
CREAR hola / package.json (1281 bytes)
CREAR hola / README.md (1021 bytes)
CREAR hola / tsconfig.json (543 bytes)
CREAR hola / tslint.json (1953 bytes)
CREAR hola / .editorconfig (246 bytes)
CREAR hola / .gitignore (631 bytes)
CREAR hola / lista de navegadores (429 bytes)
CREAR hola / karma.conf.js (1016 bytes)

npm ERR! Puede encontrar un registro completo de esta ejecución en:
npm ERR! C: \ Users \ Hanzell \ AppData \ Roamingnpm-cache_logs \ 2020-03-01T05_15_55_441Z-debug.log
× Falló la instalación del paquete, ver arriba.
El flujo de trabajo del esquema falló. Véase más arriba.
CREAR hola / src / assets / .gitkeep (0 bytes

¡ayuda!

@RiveraHan, los problemas que está teniendo no están relacionados con la desaprobación de request .

Dicho esto, tenía curiosidad. Aunque no he usado angular desde sus días en JS, lo intenté. Tenga en cuenta que no quería agregar el cli angular a mis módulos globales, por lo que procedí de manera un poco diferente. Probé lo siguiente con npm 6.14.1 , node 12.16.1 y 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

Si instala el cli angular globalmente, simplemente elimine ../w1/node_modules/.bin/ y w1/node_modules/.bin/ de arriba ng debería encontrarse globalmente.

@millette No funcionó en Linux ubuntu y windows 10. Es la primera vez que instalo el angular

@RiveraHan no es un error. es una advertencia de npm. Si cualquier configuración que use falla en las advertencias de npm, entonces debe verificar la configuración.

@csvan Pero, me di cuenta al abrir el nuevo proyecto en mi editor de código que no aparece la carpeta node_modules y hago una pequeña investigación para generar nuevamente la carpeta node_modules y es con el comando npm install lo hago y lo mismo aparece otro error .

@RiveraHan sí, pero nuevamente esto no tiene nada que ver con request o npm - las advertencias npm no interrumpirán una instalación a menos que su entorno de desarrollo esté configurado de alguna manera para hacerlo. Debe investigar por qué su entorno no tolera las advertencias npm y qué puede hacer al respecto, si ese es el problema en su caso. Bien podría ser algo completamente diferente.

@ anton-bot, así que ofrezca hacerse cargo del proyecto y poner todo el trabajo que los mantenedores actuales no tienen tiempo para hacer. Es bastante arrogante decirles a los demás cómo ejecutar su proyecto si no estás dispuesto a esforzarte tú mismo para que esto suceda. Es de código abierto.

@mikeal ha explicado claramente por qué request está en desuso. Es lo más responsable, es una buena decisión y es poco probable que se revierta.

También esto:

Además, de manera realista, la gente no va a reemplazar su código de trabajo perfectamente bueno que usa request con otra cosa. Vea algunas de las solicitudes de extracción vinculadas, simplemente no es una idea que la gente quiera hacer.

Es por eso que terminamos con un código heredado basura que depende de módulos antiguos que eran "un código perfectamente bueno" en su día. Parte del mantenimiento del software es deshacerse de los módulos antiguos y obsoletos, reemplazándolos por otros mantenidos activamente.

@ anton-bot Simplemente use @root/request que es básicamente una implementación de request que cumple con el 80% y que usa modernas API de Node HTTP bajo el capó.

@ anton-bot Claramente te estás perdiendo varios hechos de la vida:

  1. Este es un software gratuito de código abierto. No tiene derecho a decirle a los mantenedores que "simplemente detengan".
  2. La solicitud superó su fecha de caducidad (aunque no su fecha de caducidad). Se ha vuelto pesado y anticuado.
  3. @mikeal ha producido al menos dos paquetes nuevos que reemplazan a request. Ambos son mucho más ligeros.
  4. Si usted y otros desean continuar usándolo, puede hacerlo. Nada en la desaprobación le impide hacerlo.

Personalmente, he aprovechado la oportunidad para actualizar mis paquetes gradualmente. kraken-exchange , por ejemplo, ha bajado de 5,9 MB a 284 KB instalados, al cambiar a doblado .

@csvan dijo que eras "bastante arrogante". Esa es una frase mucho más educada de la que habría usado.

@ anton-bot Simplemente use @ root / request, que es básicamente una implementación de solicitud que cumple con el 80% y que utiliza API modernas de Node HTTP bajo el capó.

El 80% de cumplimiento no es lo suficientemente bueno.

Utilizo dependencias que dependen del 20% faltante (por ejemplo, flujos). Para eso, necesita un reemplazo directo con funciones completas como postman-request .

Sugerí en un comentario anterior (que parece haber sido censurado / eliminado) que los mantenedores entregaron su proyecto al equipo de Postman, para que pudieran reemplazar la implementación de postman-request request con la implementación de postman-request , ya que ese paquete aún se mantiene de forma activa, tiene funciones completas y corrige algunos de los errores que nunca se corrigieron en request .

De esa manera, los autores originales de request podrían dar un paso atrás y disfrutar de su bien merecida "jubilación" sin asustar o molestar a mucha gente al depreciar request innecesariamente.

Este es un software gratuito de código abierto. No tiene derecho a decirle a los mantenedores que "simplemente detengan".

Seguro que lo hace. Y lo mismo, los mantenedores tienen derecho a decir "f * you".

La solicitud superó su fecha de caducidad (aunque no su fecha de caducidad). Se ha vuelto pesado y anticuado.

Todavía no es una razón válida para desaprobarlo.

@mikeal ha producido al menos dos paquetes nuevos que reemplazan a request. Ambos son mucho más ligeros.

¿Entonces?

Miles de paquetes todavía están usando request hoy, y ahora están produciendo innecesariamente advertencias de depreciación durante npm install . Esto no debería haber sucedido y podría haberse evitado fácilmente, por ejemplo. entregando la antorcha al equipo de Postman o simplemente dejando que este proyecto muera en paz.

Si usted y otros desean continuar usándolo, puede hacerlo. Nada en la desaprobación le impide hacerlo.

Claro que sí.

Los clientes que se ponen nerviosos cuando ven advertencias de depreciación durante npm install impiden que muchos de nosotros nos quedemos sin hacer nada.

Desaprobación = una llamada a la acción. Básicamente, le da a las personas un período de gracia para reemplazar sus dependencias hasta que se rompan. No debe usarse en ningún otro caso, excepto en los casos en los que se espera que las dependencias rompan la funcionalidad existente después de que finalice un período de gracia.

Personalmente, he aprovechado la oportunidad para actualizar mis paquetes gradualmente. kraken-exchange, por ejemplo, ha bajado de 5,9 MB a 284 KB instalados, al cambiar a doblado.

Intenté reemplazar varias de nuestras dependencias con versiones locales internalizadas / personalizadas de esos paquetes y reemplacé request con request-postman para deshacerme de las advertencias de obsolescencia. Esto parecía una solución fácil, que luego nos permitiría reemplazar gradualmente request-postman con una alternativa más liviana.

Luego me enteré de que NPM tiene muchos errores con respecto al manejo con paquetes locales que a su vez dependen de paquetes locales, lo que hizo que nuestro entorno fuera significativamente menos estable. Abrió una nueva lata de gusanos, de verdad, así que tuve que revertir mis cambios y volver a request , ya que simplemente no valía la pena el tiempo y el esfuerzo para tratar de solucionar este tipo de problema en este momento. punto en el tiempo.

Por ahora, no veo otra alternativa que vivir con las advertencias de desaprobación, ya que simplemente usamos demasiadas dependencias que tienen request como dependencia para deshacernos de ellas con muy pocos dolores de cabeza. ¡Esto es lamentable y en mi opinión nunca debería haber sucedido!

@csvan dijo que eras "bastante arrogante". Esa es una frase mucho más educada de la que habría usado.

¿Quién eres tú para llamar a una persona "arrogante" o peor, solo porque no entiendes por qué las advertencias de desaprobación son importantes para ellos y sus proyectos?

Lo que encuentro arrogante es simplemente desaprobar un proyecto del que dependen millones de otros proyectos sin una buena razón, en lugar de buscar un mantenedor diferente que se haga cargo de usted. Y considerando que el equipo de Postman ya tiene una bifurcación con funciones completas de request que se mantiene activamente, no puedo imaginar que hubiera sido muy difícil convencerlos de que hicieran esto.

¿Cuál es su estimación, en millones de dólares, del costo mundial de esta decisión de desaprobar request ?

Cero. Funciona tan bien como siempre. Simplemente no mejorará.

Cero. Funciona tan bien como siempre. Simplemente no mejorará.

¡Mierda!

Si cree que las advertencias de desaprobación no tienen ningún impacto en los proyectos que dependen de ellas, no tiene ni idea de lo que implica la desaprobación y para qué están destinados esos mensajes.

La depreciación pone a mucha gente muy nerviosa, y con razón. ¡Eso es lo que se supone que debe hacer la desaprobación!

Ah, entonces no hay problema. Mis cálculos iniciales son de aproximadamente USD $ 30 millones, pero supongo que estaba equivocado.

USD $ 30 millones me suena como una estimación muy baja, considerando cuántos paquetes dependen de este proyecto, ya sea directa o indirectamente.

Estoy asombrado y asombrado de cuántas personas aquí piensan que tienen derecho al software libre.

Estoy asombrado y asombrado de cuántas personas aquí piensan que tienen derecho al software libre.

Estoy asombrado y asombrado de cuántas personas piensan que no tienen responsabilidad alguna con respecto a cómo sus acciones impactan a sus usuarios solo porque sus productos son gratuitos o de código abierto.

En mi opinión, es una cuestión de respeto básico tratar a sus usuarios / clientes de la misma manera, ya sea que estén pagando por usar su aplicación / biblioteca o si no están pagando.

¿Alguna vez desaprobaría un proyecto utilizado por millones de otros proyectos como una dependencia si la gente estuviera pagando por él a menos que tuviera una muy, muy, muy buena razón para ello? tiempo)?

@jslegers Mi punto exactamente. ¡Tan titulado! ¡Increíble!

@jslegers Mi punto exactamente. ¡Tan titulado! ¡Increíble!

Maceta...

Pava...

No puedo pensar en nada más legítimo que argumentar que los usuarios, de una forma u otra, te "deben" por darles software de código abierto y que deben sentirse "honrados" o "agradecidos" contigo y, por lo tanto, no tienen derecho a quejarse en absoluto. cuando sus acciones impactan directamente en sus proyectos.

Claro, mantener un proyecto de código abierto durante años requiere mucho trabajo y dedicación. Claro, es algo digno de admiración cuando las personas están dispuestas a hacer eso en su propio tiempo libre sin ninguna compensación económica. Pero eso todavía no es excusa para actuar con todo derecho y dejar a sus usuarios en el frío cuando más lo necesitan, ¡y hay varias alternativas sin esfuerzo!

@CliffS

Personalmente, he aprovechado la oportunidad para actualizar mis paquetes gradualmente. kraken-exchange, por ejemplo, ha bajado de 5,9 MB a 284 KB instalados, al cambiar a doblado.

Acabo de echar un vistazo y el package.json todavía hace referencia a la versión de solicitud 2,88.0

Acabo de echar un vistazo y el package.json todavía hace referencia a la versión de solicitud 2,88.0

@JonathanRowell Sí. Actualmente se está probando antes de enviarlo a npm. La versión v1.9.0 estará disponible al final del día.

Pero eso todavía no es excusa para actuar con todo derecho y dejar a sus usuarios en el frío cuando más lo necesitan, ¡y hay varias alternativas sin esfuerzo!

Exactamente, es por eso que tenemos personas como @jslegers dispuestas a dedicar algunas horas de su tiempo libre todos los días para ayudar con el mantenimiento, nivelar la carga de trabajo y llevar adelante el proyecto, ¡en lugar de quejarse de un problema!

Oh espera.

Exactamente, es por eso que tenemos personas como @jslegers dispuestas a dedicar algunas horas de su tiempo libre todos los días para ayudar con el mantenimiento, nivelar la carga de trabajo y llevar adelante el proyecto, ¡en lugar de quejarse de un problema!

¡Incorrecto!

Es por eso que contamos con la amable gente del equipo de Postman , que ya tiene su propio request fork llamado postman-request , que puede actuar como un reemplazo directo de funciones completas por request y que se mantiene activamente! La alternativa de sentido común a la depreciación de request sería pedirles que se hagan cargo del mantenimiento de request .

En caso de que la gente de Postman se niegue por alguna razón, request aún podría recomendar oficialmente postman-request como un reemplazo directo de funciones completas en la advertencia de depreciación, para evitar que los recursos se desperdicien innecesariamente por cientos - de no miles, de desarrolladores que buscan independientemente un reemplazo de este tipo.

Alternativamente, podría simplemente anunciar la eliminación oficial del mantenimiento / soporte de request y dejar que muera lenta y pacíficamente sin una advertencia de desaprobación, ya que realmente no hay necesidad de desaprobar O continuar con el mantenimiento de un paquete que funciona perfectamente bien y no No está a punto de romperse en un futuro próximo.

Cualquiera de estos 3 enfoques sería infinitamente mejor que el enfoque actual y no requeriría recursos adicionales de ninguna de las partes.

No creo que discutir si uno o el otro se ajusta a sus expectativas es constructivo ni ayudará a abordar los problemas en cuestión. Todos tomamos y damos, y cooperamos entre nosotros con la esperanza de que los propios problemas puedan resolverse más fácilmente, pero nadie puede obligar al otro a actuar en contra de su voluntad.

Creo que los hechos son que a) el propietario actual ya no quiere seguir adelante con el proyecto (perfectamente comprensible), pero también que b) muchas personas sienten mucho dolor por la advertencia de desaprobación, ya que la migración no lo hará. suceden inmediatamente la mayor parte del tiempo (perfectamente comprensible también).

Entonces me parece que un compromiso razonable sería, de manera similar a lo que sugiere @jslegers , que la propiedad del proyecto se transfiera a alguien interesado y dispuesto a tomarlo, elimine la advertencia de depreciación por ahora y administre el proceso de depreciación de una manera que sea más suave con los afectados por la mudanza.

Entonces, @mikeal , ¿estás dispuesto a ceder la propiedad del proyecto a otra persona?

¿Y alguien más está dispuesto a aceptarlo de Mikeal para resolver el problema que tiene la gente con la emisión de la advertencia?

Además de la cooperación para entregar la propiedad del proyecto, ninguno de nosotros puede hablar por los demás, diciéndoles que hagan esto o aquello; uno solo puede hablar por uno mismo.

Otro hecho que no se ha mencionado mucho en este hilo es el impacto en la seguridad de transferir la propiedad de un paquete tan popular. Hemos tenido incidentes recientes en los que una transferencia de propiedad fue a un mal actor y resultó en actividad maliciosa en nuevas versiones del paquete. Los paquetes populares como este son grandes objetivos para ese tipo de actor.

No comentaré sobre la confiabilidad de ningún equipo específico que pueda asumir la responsabilidad, pero es importante reconocer cuán arriesgada es realmente tal sugerencia. La desaprobación de este paquete no evita que las bifurcaciones sigan manteniendo este paquete con un nombre diferente, pero el cambio de nombre permite al consumidor tomar la decisión de consumir esa bifurcación en lugar de que suceda automáticamente sin la oportunidad de evaluar el riesgo de su proyecto.

Otro hecho que no se ha mencionado mucho en este hilo es el impacto en la seguridad de transferir la propiedad de un paquete tan popular. Hemos tenido incidentes recientes en los que una transferencia de propiedad fue a un mal actor y resultó en actividad maliciosa en nuevas versiones del paquete. Los paquetes populares como este son grandes objetivos para ese tipo de actor.

Obviamente, no puede simplemente transferir la propiedad a cualquiera. Pero el equipo de Postman parece una elección lógica, porque ...

  • Tienen una reputación que proteger y, por lo tanto, no pueden permitirse dañar el proyecto request inyectando código malicioso en el proyecto.
  • Como plataforma para el desarrollo y las pruebas de API, puede ser una ventaja de marketing para ellos convertirse en el mantenedor oficial de un paquete de NPM muy popular utilizado por muchos de sus clientes potenciales.
  • Como ya mantienen su propia bifurcación de request , no debería requerir recursos adicionales de ellos. Podrían simplemente fusionar su bifurcación en request y mover recursos desde su propia bifurcación (que ya no sería necesaria) al repositorio oficial request

Obviamente, no hay garantía de que lo acepten. Pero si tuvieran algo de sentido común, se lanzarían a esto de inmediato. Entonces, a menos que un mantenedor de request ya haya intentado comunicarse con ellos y pueda confirmar que, de hecho, rechazaron esta propuesta, ¡definitivamente vale la pena intentarlo!

Realmente no hay necesidad de desaprobar O continuar con el mantenimiento de un paquete que funciona perfectamente bien y no está a punto de romperse en un futuro cercano.

Esto es tan al revés que ni siquiera sé por dónde empezar. El hecho de que un paquete no se mantenga y se recomiende alejarlo es todo el punto de desaprobación.
El propietario le hace saber que está generando deuda técnica al usarla para que pueda seguir adelante. Lo mejor de una desaprobación oficial a través de npm es exactamente que las personas reciben una indicación clara de esto, en lugar de tener que descubrirlo años después (en su escenario "déjelo morir lentamente") donde probablemente ya sea demasiado tarde para considere una migración sin problemas.

Los paquetes ampliamente utilizados y posteriormente abandonados no mueren pacíficamente. Mueren cuando las personas que los usan comienzan a alejarse presas del pánico después de que su estado no mantenido en realidad conduce a que se rompan las cosas y se abran agujeros de seguridad.

Acéptelo, ni usted ni yo probablemente hubiéramos sabido el estado de la solicitud sin el aviso de desaprobación. Tampoco lo haría la gran mayoría de usuarios.

Intenté instalar angular en linux y luego en windows y en ambos no pude, luego de ejecutar el comando npm install -g @ angular / cli @ latest en ambos me apareció este error

C: \ Users \ Hanzell> npm install -g @ angular / cli @ latest
npm WARN obsoleto [email protected]: la solicitud ha quedado obsoleta, 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

Luego, creé el repositorio y apareció este

C: \ Users \ Hanzell \ Desktop> ng nuevo
? ¿Qué nombre le gustaría usar para el nuevo espacio de trabajo y el proyecto inicial? Hola
? ¿Le gustaría agregar enrutamiento angular? No
? ¿Qué formato de hoja de estilo le gustaría utilizar? CSS
CREAR hola / angular.json (3551 bytes)
CREAR hola / package.json (1281 bytes)
CREAR hola / README.md (1021 bytes)
CREAR hola / tsconfig.json (543 bytes)
CREAR hola / tslint.json (1953 bytes)
CREAR hola / .editorconfig (246 bytes)
CREAR hola / .gitignore (631 bytes)
CREAR hola / lista de navegadores (429 bytes)
CREAR hola / karma.conf.js (1016 bytes)

npm ERR! Puede encontrar un registro completo de esta ejecución en:
npm ERR! C: \ Users \ Hanzell \ AppData \ Roamingnpm-cache_logs \ 2020-03-01T05_15_55_441Z-debug.log
× Falló la instalación del paquete, ver arriba.
El flujo de trabajo del esquema falló. Véase más arriba.
CREAR hola / src / assets / .gitkeep (0 bytes

¡ayuda!

Verifique la actualización de npm y luego la instalación de npm en el proyecto angular

Esto es tan al revés que ni siquiera sé por dónde empezar. El hecho de que un paquete no se mantenga y se recomiende alejarlo es todo el punto de desaprobación.

Que un paquete no se mantenga y REQUIERA que se retire antes de que finalice un período de gracia es el punto de desaprobación.

Si no hay ningún requisito para mudarse antes de un momento específico en el tiempo, no debe desaprobar ... al menos no a menos que pueda proponer un reemplazo directo (como postman-request en este caso).

La diferencia puede ser sutil, pero la consecuencia es significativa. Está desperdiciando los recursos de posiblemente muchos miles de empresas sin una buena razón al depreciar, lo que podría evitarse simplemente terminando el mantenimiento y dejándolo así.

Otro hecho que no se ha mencionado mucho en este hilo es el impacto en la seguridad de transferir la propiedad de un paquete tan popular. Hemos tenido incidentes recientes en los que una transferencia de propiedad fue a un mal actor y resultó en actividad maliciosa en nuevas versiones del paquete. Los paquetes populares como este son grandes objetivos para ese tipo de actor.

... desaprobar este paquete no evita que las bifurcaciones continúen manteniendo este paquete con un nombre diferente

Lo suficientemente justo; Supongo que podemos esperar un poco para tener noticias de la gente de Postman y evaluar si la transferencia a ellos es viable; pero por lo demás, las bifurcaciones parecen ser el camino a seguir.

No, no está perdiendo el tiempo a nadie al dejar en claro que una de sus dependencias ahora está abandonada y es casi seguro que una fuente de deuda técnica. Todo lo contrario es cierto, y toda la discusión sobre este tema es una prueba de ello, una discusión que probablemente no habría sucedido en el corto plazo sin la desaprobación.

No, no está perdiendo el tiempo a nadie al dejar en claro que una de sus dependencias ahora está abandonada y es casi seguro que una fuente de deuda técnica.

El hecho de que se abandone un proyecto no significa que deba ser reemplazado por otra cosa.

Especialmente para proyectos que usan múltiples dependencias que usan request como una dependencia ellos mismos, la ganancia potencial de intentar reemplazar request con otra cosa ni siquiera se acerca al esfuerzo requerido para lograr esto !

una discusión que probablemente no habría ocurrido pronto sin la desaprobación.

Esta discusión no habría sido necesaria sin la desaprobación.

Sí, lo haría en algún momento, con o sin una desaprobación. Siempre es mejor llegar a ese punto antes que años después, cuando comienzan a sentirse los efectos de un paquete sin mantenimiento.

De todos modos, renuncio a esto. Divertirse.

“Todo es cambiante, todo aparece y desaparece; no hay paz dichosa hasta que uno pasa más allá de la agonía de la vida y la muerte ”.

- Buda Gautama

@mikeal Eres un

Antes de entrar en detalles y razonar, iré directo al grano. Lo más valioso que puede hacer request por el ecosistema de JavaScript es entrar en modo de mantenimiento y dejar de considerar nuevas funciones o versiones importantes.

Disculpas de antemano a los otros confirmadores de request que han estado haciendo todo lo posible para mejorarlo, pero es lo mejor.

2009

La primera versión de request fue uno de los primeros módulos creados para el ecosistema Node.js. Las primeras versiones se escribieron en API que son anteriores a la interfaz de devolución de llamada estándar, streams, node_modules y npm. Durante los primeros años, request y Node.js evolucionaron juntos, cada uno aprendiendo del otro. A medida que Node.js mejoró y migró las interfaces centrales, también lo solicitó. A medida que la solicitud adoptó cambios en la biblioteca http central y las transmisiones, también informó mejoras como el evento pipe (que habilitó el proxy de una línea de request ) y una de las muchas reescrituras de Core http (la uno que tenía que escribir).

npm

request fue uno de los primeros módulos agregados al registro npm. A medida que el npm creció, también lo hizo la dependencia de request . Incluso ahora, cuando npm se usa mucho más para el front-end que para el back-end, request sigue siendo uno de los módulos más dependientes del registro. Mientras escribo esto, los módulos de 41K dependen de la solicitud y se descargan 14 millones de veces a la semana.

El lugar que tiene request en el ecosistema de Node.js ya no es el de un innovador sino el de un incumbente. Si busca en Google cómo hacer algo con HTTP en Node.js, es probable que los ejemplos muestren request como cliente y express como servidor. Esto tiene dos efectos notablemente negativos.

Es mucho más difícil para las nuevas bibliotecas que realizan tareas similares lograr la adopción debido a la posición actual que request tiene sobre el ecosistema. También es muy difícil cambiar la solicitud de una manera significativa, ya que el cambio no solo puede no ser adoptado por la mayoría de sus dependientes, sino que lo desalinearía con las miles de publicaciones de blog y las respuestas de desbordamiento de la pila que usan request .

JavaScript moderno

Los últimos años han sido dramáticos en JavaScript. Las características de las que la gente había hablado durante años iban desde las ideas hasta los estándares y las características de las que puede depender de manera confiable en la mayoría de los entornos. La velocidad a la que se han adoptado es asombrosa, principalmente gracias a los navegadores que se actualizan automáticamente y a un programa de lanzamiento agresivo de Node.js.

Los patrones en el núcleo de request están desactualizados. Algunas personas podrían discutir con esa evaluación, y yo sé quiénes son, así que no me sorprenderá, pero es cierto. A menudo he sido escéptico sobre el impacto que tendrían algunas de estas características solo para encontrarme adoptándolas al por mayor poco después de que estén disponibles solo en la última versión de Node.js.

Ahora se está produciendo una transición en el ecosistema a estos patrones. Lo desordenado que será eso todavía está en el aire y no voy a intentar leer las hojas de té y descubrir cómo se ve el futuro en ese sentido. La pregunta para request es "¿Intentamos sobrevivir a través de esa transición?" Hace un año pensaba que la respuesta era obvia y que lo haríamos, pero ahora estoy convencido de lo contrario.

Una versión de request escrita para adoptar realmente estos nuevos patrones de lenguaje es, efectivamente, un nuevo módulo. Ya he explorado un poco este espacio y tengo un proyecto con el que estoy bastante contento, pero es incompatible con request en todas las formas imaginables. ¿Cuál es el valor en una versión de request que es incompatible con los patrones antiguos pero que no acepta completamente los nuevos? ¿De qué sirve ser parcialmente compatible cuando hay todo un mundo de módulos nuevos, escritos por nuevos desarrolladores, que están reconsiderando estos problemas con estos patrones en mente?

Lo mejor para estos nuevos módulos es que request se desvanezcan lentamente, convirtiéndose eventualmente en una memoria más de esa pila heredada. Tomar la posición que request tiene ahora y aprovecharla para una mayor proporción de la próxima generación de desarrolladores sería un flaco favor para esos desarrolladores, ya que los alejaría de mejores módulos que no tienen la carga de request Historial de

Modo de mantenimiento

Este es el plan.

  • request dejará de aceptar nuevas funciones.
  • request dejará de considerar cambios importantes.
  • Los confirmadores que aún están activos intentarán fusionar las correcciones de manera oportuna, aunque sin promesas.
  • Las versiones se automatizarán por completo y se publicará cualquier combinación con la versión maestra. Ya construí esto para algunos otros proyectos usando acciones de GitHub .

    • Tendremos que eliminar a los colaboradores inactivos y hacer cumplir la 2fa, porque los derechos de confirmación se convertirán efectivamente en derechos de publicación de npm.

¿Qué pasa si simplemente lo borramos? ¡estas dependencias son un asesino!

@grikard Estoy de acuerdo con eso, buen análisis. Pero sin querer sonar trivial, esta es una pregunta genuina, ¿escriben los estadounidenses el plural de "hoja" como hojas? Lernt "hojas".

hojas es plural para hoja :)

Instalando paquetes ... npm WARN obsoleto [email protected] : la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142
si alguien más va aquí porque tiene un error sobre
ng new my-app
intentar otra vez
sudo ng new my-app
feliz pirateo

Hola, ¿cómo se resuelve este error? https://github.com/request/request/issues/3142

Hola, ¿cómo se resuelve este error? N.º 3142

¿Qué error?

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

El miércoles, 11 de marzo de 2020, 8:23 p. M. Cliff Stanford [email protected]
escribió:

Hola, ¿cómo se resuelve este error? N.º 3142
https://github.com/request/request/issues/3142

¿Qué error?

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/request/request/issues/3142#issuecomment-597602350 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AN6OSLTSIY5LZVUEOX3JWHDRG57FNANCNFSM4HCP6LRA
.

No puedo completar mi proyecto por esto ... y vence esta noche. ¿Alguien puede ayudar a solucionar este problema en la solicitud?

@AELDREI Esto no es un error. La obsolescencia es solo una advertencia / información, todo sigue funcionando.
@ valentina-js "Esto" es solo una advertencia / información, por lo que no puede ser la causa de que no puedas terminar tu proyecto. Si tiene un problema, debe tener otra causa. Intente buscar un mensaje de error real y vea si hay un problema similar informado. Si no es así, abra uno y describa su error en detalle.

Oh no. No era necesario. Rotura

Mercancía nueva

Screenshot_2020-03-12_16-58-39

3sei8v

npm WARN obsoleto [email protected] : la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142

¡Por favor resuelve esto! No se que estoy haciendo mal:

npm WARN obsoleto [email protected] : la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142
npm WARN checkPermissions Falta el acceso de escritura a / usr / local / lib / node_modules
npm ERR! código EACCES
npm ERR! acceso syscall
npm ERR! ruta / usr / local / lib / node_modules
npm ERR! errno -13
npm ERR! Error: EACCES: permiso denegado, acceso '/ usr / local / lib / node_modules'
npm ERR! [Error: EACCES: permiso denegado, acceso '/ usr / local / lib / node_modules'] {
npm ERR! pila: "Error: EACCES: permiso denegado, acceso '/ usr / local / lib / node_modules'",
npm ERR! errno: -13,
npm ERR! código: 'EACCES',
npm ERR! syscall: 'acceso',
npm ERR! ruta: '/ usr / local / lib / node_modules'
npm ERR! }
npm ERR!
npm ERR! La operación fue rechazada por su sistema operativo.
npm ERR! Es probable que no tenga los permisos para acceder a este archivo como usuario actual
npm ERR!
npm ERR! Si cree que esto podría ser un problema de permisos, vuelva a verificar el
npm ERR! permisos del archivo y los directorios que lo contienen, o intente ejecutar
npm ERR! el comando nuevamente como root / administrador.

npm ERR! Puede encontrar un registro completo de esta ejecución en:
npm ERR! /Users/Hazem/.npm/_logs/2020-03-15T16_16_03_301Z-debug.log

@hazembergg NPM no tiene acceso de escritura a node_modules. No hay nada de malo en request que bloquee npm install . Intente ejecutarlo con sudo .

Gracias por tu pronta respuesta, ¡funcionó a las mil maravillas!

¡Así que creo que me estoy volviendo loco! Debo haber leído README al menos 20 veces. Todo este programa está por encima de mi conocimiento básico de html ...

_¿Cómo obtengo comentarios de youtube? _
¿Ejecuto youtube-comment-scraper? en el nodo? terminal básico? o mando?
la respuesta del nodo es ...
la respuesta del terminal es que el título cambia pero no pasa nada

_¿Y si deseo tener un archivo csv? _
es el comando: youtube-comment-scraper --outputFile youtubecomments.csv --stdout --format csv ¿correcto?

_Ballpark ¿cuánto tardaría en ejecutarse el programa para obtener, digamos, mil comentarios? _

@hazembergg Ambos. Consulte https://www.npmjs.com/package/youtube-comment-scraper#usage para ver el uso de la línea de comandos y https://www.npmjs.com/package/youtube-comment-scraper#method para el uso programático. También puede ejecutar npx youtube-comment-scraper con Node.js instalado en la línea de comando para acceder a la CLI.

@Richienb ¡ Gracias de nuevo por la información! ¡Los estudiaré y espero tener éxito!

Sí, parece que todo el mundo está haciendo algo mal. Me han dicho que la decisión de desaprobar request tendría un costo cero.

¡Nunca hay costo cero!

Estoy enfrentando un problema con la creación del túnel de salsa.
Utilizando el siguiente servicio de salsa.
npm install -g wdio-sauce-service
25hnpm WARN obsoleto [email protected] : la solicitud ha quedado obsoleta, 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
secuencias de comandos de nodo / install.js || scripts de nodejs / install.js

+ [email protected]

Obteniendo el siguiente error al intentar crear el túnel de salsa.
No se pudo iniciar Sauce Connect. Señal del código de salida 1: nulo
Un servicio falló en el gancho 'onPrepare'
Error: no se pudo iniciar Sauce Connect. Señal del código de salida 1: nulo
en ChildProcess.(/usr/local/lib/node_modules/wdio-sauce-service/node_modules/sauce-connect-launcher/lib/sauce-connect-launcher.js:566:12)
en ChildProcess.emit (events.js: 198: 13)
en ChildProcess.EventEmitter.emit (dominio.js: 448: 20)
en Process.ChildProcess._handle.onexit (internal / child_process.js: 248: 12)

Sea respetuoso y evite publicar preguntas serias. Solo memes sobre request .

@ anton-bot déjalo ir y sigue adelante con tu vida.

Sea respetuoso y evite publicar preguntas serias. Solo memes sobre request .

@ anton-bot déjalo ir y sigue adelante con tu vida.

Let it go

Volviendo a la seriedad, ahora que request ha sido "oficialmente" obsoleto a través de npm deprecate , ahora _todos_ los usuarios ascendentes reciben nuevas advertencias al respecto.

¿Podemos considerar esto por un momento? Creo que esto ha provocado un pánico indebido. No solo eso, sino que los sistemas automatizados que confirman sus registros ahora hacen referencia a este problema debido a la clave del problema en la advertencia de obsolescencia.

Estoy de acuerdo en que request ha madurado hasta el punto de la obsolescencia, pero si aún funciona bien y tiene cientos de dependencias con diferentes niveles de mantenimiento, tal vez no debería estar oficialmente en desuso en npm sino más bien ¿Advertencia grande en el tipo de letra máximo en el archivo README?

Y luego, un día, cada uno de esos usuarios dirá: "¿¡Por qué no nos advirtieron sobre esto !?" 😄

pero si todavía funciona bien y tiene cientos de dependencias con diferentes niveles de mantenimiento, ¿quizás no debería estar oficialmente desaprobado en npm sino más bien una gran advertencia en la fuente máxima en el archivo README?

El problema es que esencialmente _ nadie_ los lee. El 99% de las personas que ahora están en pánico nunca habrían sabido que la solicitud estaba en desuso a menos que NPM les advirtiera al respecto. _Nadie_ se sienta y revisa el archivo README de _todas_ sus dependencias para averiguar cuáles ya no se mantienen, hasta que es demasiado tarde.

Me estoy repitiendo, pero el escenario que propones esencialmente significa que las personas descubrirán por las malas que la solicitud está desaprobada, cuando finalmente comience a romper cosas y cause agujeros de seguridad debido a que es un depósito antiguo y sin mantenimiento en un entorno moderno. Cuando eso suceda, la gente tendrá que buscar una alternativa, en lugar de tener la oportunidad, como es ahora, de buscar una mientras la solicitud aún sea estable y utilizable, lo que probablemente sea otro año al menos.

Desaprobar la solicitud fue lo más responsable y no se va a revertir. La comunidad debe centrar sus esfuerzos en acordar una buena alternativa y / o bifurcación en lugar de tratar de cambiar esto. Siga adelante.

WARN obsoleto [email protected] : la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142 .
¿Cómo puedo corregir ese error?

@mrmehi ¿Puedes leer el primer mensaje aquí?

No es un error. O depende directamente de la solicitud (y luego debe moverse a otra biblioteca, por ejemplo, got o bent ), o depende transitivamente de ella a través de una de sus dependencias, luego actualícela si ya se movió, o haga ping a ellos para seguir adelante.

@kibertoad Estoy realmente confundido, ¿qué debo hacer ahora?
sucede cuando intento descargar expo.io

@kibertoad Estoy realmente confundido, ¿qué debo hacer ahora?
sucede cuando intento descargar expo.io

No tienes que hacer nada. No es un error, es una advertencia. Eso es lo que indica la parte "ADVERTENCIA" del registro.
_Podría_ hacer que expo.io sea consciente de que es posible que quieran comenzar a buscar alternativas a request , porque está obsoleto y, por lo tanto, algún día podría dejar de funcionar correctamente.
Pero parece que ya lo saben, como puede ver aquí:
https://github.com/expo/expo-cli/issues/1659

Microsoft todavía confía en este paquete. appcenter-cli da esta advertencia de obsolescencia en la instalación:

npm WARN obsoleto [email protected] : la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142

Dado el historial del equipo de AppCenter, parece poco probable que esto cambie pronto. Nuestros registros de compilación están llenos de advertencias sobre paquetes que se desaprobaron hace más de un año en algunos casos.

Por favor, alguien puede ayudarme. Tengo dificultades al instalar expo-cli --global.
He instalado el nodo, git. Escribo el comando como npm install expo-cli --global pero enfrento un problema como:
"npm WARN obsoleto [email protected] : la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142
[..................] | fetchMetadata: WARN obsoleto [email protected] : la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142 "".
lo que me sale este error. por favor, respóndeme cómo resolver este problema.

@mrmehi ¿Puedes leer el primer mensaje aquí?

No es un error. O depende directamente de la solicitud (y luego debe moverse a otra biblioteca, por ejemplo, got o bent ), o depende transitivamente de ella a través de una de sus dependencias, luego actualícela si ya se movió, o haga ping a ellos para seguir adelante.

por favor, ¿pueden ayudarme a resolver este problema? estoy enfrentando el problema.

@lemessur Resulta que los mantenedores simplemente no sabían que la solicitud estaba obsoleta. Consulte https://github.com/microsoft/appcenter-cli/pull/758#issuecomment -603667106

Alguien, ponga esto en la parte superior del comentario del problema principal:

Aviso de baja

Si obtiene WARN deprecated [email protected]: request has been deprecated, see #3142 al intentar instalar sus dependencias, tenga la seguridad de que esto NO es un error. El autor del paquete que está instalando (o usted, si depende de request ) debe migrar a otra biblioteca. Ver: https://github.com/request/request/issues/3143

@Richienb
Ver # 3142 (comentario)

Entonces que deberia hacer ahora . por favor, ¿pueden ayudarme a resolver este problema?

@Richienb
Ver # 3142 (comentario)

Soy nuevo en github y no pude entender qué hacer. ¿Puede decirme paso a paso cómo puedo resolver mi problema? buscando su respuesta rápida.

@alijatoi expo-cli está usando request por lo tanto, su dependencia debe cambiarse.

@Richienb Entonces, ¿qué debo hacer ahora? ¿Debo esperar o hay alguna otra forma de instalar expo-cli?
por favor ayúdame esperando.
gracias

@alijatoi Crea un problema y / o espera.

@Richienb gracias por tu respuesta.
no hay otra forma de instalar expo cli?

@alijatoi no

chicos, si tiene problemas instale expo-cli con npm debido a un mensaje depreactado: instale yarn y luego yarn instale expo-cli

@ caio-vinicius Eso solo funciona porque yarn solo muestra la advertencia una vez y continuará mostrándola cuando se regenere el archivo de bloqueo.

chicos, si tiene problemas instale expo-cli con npm debido a un mensaje depreactado: instale yarn y luego yarn instale expo-cli

@ caio-vinicius sí, terminé la instalación usando install yarn, luego yarn install expo-cli globalmente, pero después de la instalación, cuando verifico la versión de expo cli, me da un problema de que expo no define ningún comando interno o externo.

@alijatoi , asegúrese de estar utilizando la sintaxis correcta cuando utilice yarn para instalar globalmente.

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

Sin embargo, @alijatoi , una instalación interrumpida por una advertencia de

Llego un poco tarde a la fiesta, pero sería bueno agregar una pequeña lista de alternativas para que la gente pueda usarlas para reemplazar request , como los nodejs integrados en http.ClientRequest . Gracias.

F

Estoy de acuerdo con todo lo que dijiste sobre forma, compatibilidad y progreso, pero
No veo por qué [email protected] no puede hacerlo con cambios importantes. Después de todo, esa es la idea detrás de semver ...

Muchas otras bibliotecas se han adaptado a los nuevos patrones y capacidades y, por lo tanto, rompieron la compatibilidad y elevaron su especialidad.

Incluso si es un módulo completamente nuevo, el nombre representa la credibilidad y
experiencia de lecciones aprendidas, que me entristece ver desaparecer.

Interesado aprender más sobre esto.

Bueno, gracias por el viaje y todo el trabajo duro que has realizado. 👍

Tú, mi señor, eres un héroe.

Entiendo la razón detrás de esto, está haciendo que JS / Node (en general) progrese un poco más rápido.

Hiciste 'casi' tanto para el espacio NodeJS como lo hizo jQuery para el navegador / espacio DOM. Ha hecho que sea un placer trabajar con TCP, y eso es fundamental para el desarrollo de back-end.

Te doy las gracias por esto.

Cuídate.

Entonces, ¿cuál es la guía sobre la forma alternativa de hacer una solicitud https para mí que es nueva para el desarrollo de back-end con node?

Gracias Cliff. Echará un vistazo.

NPM advierta alerta registro inesperado para https://registry.npmjs.org/ : EINTEGRITY Advertencia Varios: suma de comprobación sha512-7G3s83fOoweLlAsvR3wtw4DnepkrY + / FxmYxk1XnfAjE9xnoWRy9cLHWCywcc6l6018X1RdNxpJdtqX9WQAEXw == integridad falló al utilizar sha512: querido sha512-7G3s83fOoweLlAsvR3wtw4DnepkrY + / FxmYxk1XnfAjE9xnoWRy9cLHWCywcc6l6018X1RdNxpJdtqX9WQAEXw == pero obtuvo sha512-NhZAWqNqTzZaAfgJYp0NlbBDUX8BMyOmobe3kYnymXfSxDgaiej4nP6N3aLVDtBTPHOfivySRs + AVsca0JgrTQ ==. (20905 bytes)
Registro npm WARN Utilizando datos obsoletos de https://registry.npmjs.org/ debido a un error de solicitud durante la revalidación.
npm WARN obsoleto [email protected] : la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142
npm ERR! código EINTEGRITY
npm ERR! errno EINTEGRIDAD
npm ERR! Cuerpo de la respuesta no válida al intentar recuperar https://registry.npmjs.org/uuid : verificación de la integridad fracasado por sha512-7G3s83fOoweLlAsvR3wtw4DnepkrY + / FxmYxk1XnfAjE9xnoWRy9cLHWCywcc6l6018X1RdNxpJdtqX9WQAEXw == (C: \ Users \ Mulamba SERGIO \ AppData \ Roamingnpm-cache_cacache \ content-v2 \ sha512 \ ec \ 6d \ ecf377cea3078b940b2f477c2dc380e77a992b63efc5c666319355e77c08c4f719e8591cbd70b1d60b2c1c73a97ad35f17d5174dc6925db6a5fd5900045f)

npm ERR! Puede encontrar un registro completo de esta ejecución en:
npm ERR! C: \ Usuarios \ MULAMBA SERGIO \ AppData \ Roamingnpm-cache_logs \ 2020-04-03T22_54_57_842Z-debug.log

npm WARN obsoleto [email protected]: la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142
npm WARN obsoleto [email protected]: esta versión ha quedado obsoleta de acuerdo con la política de soporte de hapi (hapi.im/support). Actualice a la última versión para obtener las mejores funciones, correcciones de errores y parches de seguridad. Si no puede actualizar en este momento, hay soporte de pago disponible para versiones anteriores (hapi.im/commercial).
npm WARN obsoleto [email protected]: la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142
npm WARN obsoleto [email protected]: core-js @ <3 ya no se mantiene y no se recomienda su uso debido a la cantidad de problemas. Actualice sus dependencias a la versión real de core-js @ 3.
npm WARN obsoleto [email protected]: esta versión ha quedado obsoleta de acuerdo con la política de soporte de hapi (hapi.im/support). Actualice a la última versión para obtener las mejores funciones, correcciones de errores y parches de seguridad. Si no puede actualizar en este momento, hay soporte de pago disponible para versiones anteriores (hapi.im/commercial).
npm WARN obsoleto [email protected]: esta versión ha quedado obsoleta de acuerdo con la política de soporte de hapi (hapi.im/support). Actualice a la última versión para obtener las mejores funciones, correcciones de errores y parches de seguridad. Si no puede actualizar en este momento, hay soporte de pago disponible para versiones anteriores (hapi.im/commercial).
npm WARN obsoleto [email protected]: esta versión ha quedado obsoleta de acuerdo con la política de soporte de hapi (hapi.im/support). Actualice a la última versión para obtener las mejores funciones, correcciones de errores y parches de seguridad. Si no puede actualizar en este momento, hay soporte de pago disponible para versiones anteriores (hapi.im/commercial).
npm WARN obsoleto [email protected]: este módulo se ha movido y ahora está disponible en @ hapi / topo. Actualice sus dependencias, ya que esta versión ya no se mantiene y puede contener errores y problemas de seguridad.
npm WARN obsoleto [email protected]: este módulo se ha movido y ahora está disponible en @ hapi / hoek. Actualice sus dependencias, ya que esta versión ya no se mantiene y puede contener errores y problemas de seguridad.
C: \ Users \ Matheus \ AppData \ Roaming \ npm \ expo -> C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ bin \ expo.js
C: \ Users \ Matheus \ AppData \ Roaming \ npm \ expo-cli -> C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ bin \ expo.js
npm WARN opcional SALTANDO DEPENDENCIA OPCIONAL: @ expo / travelling-fastlane-darwin @ 1.13.1 (node_modules \ expo-cli \ node_modules \ @expo \ travelling-fastlane-darwin):
npm WARN notsup OMITIR LA DEPENDENCIA OPCIONAL: Plataforma no admitida para @ expo / travelling-fastlane-darwin @ 1.13.1: quería {"os": "darwin", "arch": "any"} (actual: {"os": " win32 "," arch ":" x64 "})
npm WARN opcional SALTO DEPENDENCIA 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 WARN notsup OMITIR LA DEPENDENCIA OPCIONAL: Plataforma no admitida para @ expo / ngrok-bin-linux-arm @ 2.2.8: quería {"os": "linux", "arch": "arm"} (actual: {"os" : "win32", "arch": "x64"})
npm WARN opcional SALTO DEPENDENCIA 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 WARN notsup OMITIR LA DEPENDENCIA OPCIONAL: Plataforma no compatible para @ expo / ngrok-bin-darwin-ia32 @ 2.2.8: quería {"os": "darwin", "arch": "ia32"} (actual: {"os" : "win32", "arch": "x64"})
npm WARN opcional SALTO DEPENDENCIA 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 WARN notsup OMITIR LA DEPENDENCIA OPCIONAL: Plataforma no compatible para @ expo / ngrok-bin-freebsd-x64 @ 2.2.8: quería {"os": "freebsd", "arch": "x64"} (actual: {"os" : "win32", "arch": "x64"})
npm WARN opcional SALTAR DEPENDENCIA 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 WARN notsup OMITIR LA DEPENDENCIA OPCIONAL: Plataforma no admitida para @ expo / ngrok-bin-freebsd-ia32 @ 2.2.8: quería {"os": "freebsd", "arch": "ia32"} (actual: {"os" : "win32", "arch": "x64"})
npm WARN opcional SALTO DEPENDENCIA 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 WARN notsup OMITIR LA DEPENDENCIA OPCIONAL: Plataforma no admitida para @ expo / ngrok-bin-linux-ia32 @ 2.2.8: quería {"os": "linux", "arch": "ia32"} (actual: {"os" : "win32", "arch": "x64"})
npm WARN opcional SALTO DEPENDENCIA 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 WARN notsup OMITIR LA DEPENDENCIA OPCIONAL: Plataforma no compatible para @ expo / ngrok-bin-linux-x64 @ 2.2.8: quería {"os": "linux", "arch": "x64"} (actual: {"os" : "win32", "arch": "x64"})
npm WARN opcional SALTAR DEPENDENCIA 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 WARN notsup OMITIR LA DEPENDENCIA OPCIONAL: Plataforma no admitida para @ expo / ngrok-bin-darwin-x64 @ 2.2.8: quería {"os": "darwin", "arch": "x64"} (actual: {"os" : "win32", "arch": "x64"})
npm WARN opcional SALTAR DEPENDENCIA 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 WARN notsup OMITIR LA DEPENDENCIA OPCIONAL: Plataforma no compatible para @ expo / ngrok-bin-win32-ia32 @ 2.2.8-beta.1: quería {"os": "win32", "arch": "ia32"} (actual: {"os": "win32", "arch": "x64"})
npm WARN opcional SALTAR DEPENDENCIA 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 WARN notsup OMITIR LA DEPENDENCIA OPCIONAL: Plataforma no compatible para @ expo / ngrok-bin-sunos-x64 @ 2.2.8: quería {"os": "sunos", "arch": "x64"} (actual: {"os" : "win32", "arch": "x64"})
npm WARN opcional SALTO DEPENDENCIA 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 WARN notsup OMITIR LA DEPENDENCIA OPCIONAL: Plataforma no compatible para @ expo / ngrok-bin-linux-arm64 @ 2.2.8: quería {"os": "linux", "arch": "arm64"} (actual: {"os" : "win32", "arch": "x64"})
npm WARN opcional SALTAR DEPENDENCIA OPCIONAL: fsevents@^1.2.7 (node_modules \ expo-cli \ node_modules \ chokidar \ node_modules \ fsevents):
npm WARN notsup OMITIR LA DEPENDENCIA OPCIONAL: Plataforma no admitida para [email protected]: quería {"os": "darwin", "arch": "any"} (actual: {"os": "win32", "arch": "x64"})
npm WARN @ expo / image-utils @ 0.2.17 requiere un par de sharp-cli@^1.10.0 pero ninguno está instalado. Debe instalar las dependencias de pares usted mismo.
npm WARN opcional SALTO DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ abbrev):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre de 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ abbrev' -> 'C: \ Usuarios \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.abbrev.DELETE '
npm WARN opcional SALTO DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ ansi-regex):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre de '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 SALTAR DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ aproba):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre de 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ aproba' -> 'C: \ Usuarios \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.aproba.DELETE '
npm WARN opcional SALTO DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ balance-match):
npm WARN enoent SALTANDO LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ balance-match' -> 'C : \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.balanced-match.DELETE '
npm WARN opcional SALTAR DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ chownr):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre de 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ chownr' -> 'C: \ Usuarios \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.chownr.DELETE '
npm WARN opcional SALTO DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ code-point-at):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre de '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 SALTO DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ concat-map):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre '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 OMITIR LA DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ console-control-strings):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre de '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 SALTO DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ core-util-is):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre de '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 SALTO DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ deep-extend):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre '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 SALTAR DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ delegates):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre de 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ delegates' -> 'C: \ Usuarios \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.delegates.DELETE '
npm WARN opcional OMITIR LA DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ detect-libc):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre '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 SALTO DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ fs.realpath):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre de 'C: \ Users \ 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 SALTO DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ has-unicode):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre de '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 SALTAR DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ hereits):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre de 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ hereits' -> 'C: \ Usuarios \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.inherits.DELETE '
npm WARN opcional SALTO DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ ini):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre de 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ ini' -> 'C: \ Usuarios \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.ini.DELETE '
npm WARN opcional SALTAR DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ isarray):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre de 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ isarray' -> 'C: \ Usuarios \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.isarray.DELETE '
npm WARN opcional SALTAR DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ minimist):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre de 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ minimist' -> 'C: \ Usuarios \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.minimist.DELETE '
npm WARN opcional SALTAR DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ ms):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ ms' -> 'C: \ Usuarios \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.ms.DELETE '
npm WARN opcional SALTAR DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ npm-normalize-package-bin):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre de 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ npm-normalize-package-bin' -> 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.npm-normalize-package-bin.DELETE'
npm WARN opcional OMITIR LA DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ number-is-nan):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre de '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 SALTAR DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ object-assign):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre '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 SALTAR DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ os-homedir):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe ese archivo o directorio, cambie el nombre de '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 SALTAR DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ os-tmpdir):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre de '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 SALTAR LA DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ path-is-absolute):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre de 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ path-is-absolute' -> 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.path-is-absolute.DELETE'
npm WARN opcional OMITIR LA DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ process-nextick-args):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre de '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 SALTAR DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ safe-buffer):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre de '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 SALTANDO DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ safer-buffer):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre '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 SALTO DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ sax):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre de 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ sax' -> 'C: \ Usuarios \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.sax.DELETE '
npm WARN opcional SALTO DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ semver):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre de 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ semver' -> 'C: \ Usuarios \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.semver.DELETE '
npm WARN opcional SALTO DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ set-block):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre de 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ set-block' -> 'C : \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.set-signing.DELETE '
npm WARN opcional SALTANDO DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ signal-exit):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre de '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 OMITIR LA DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ strip-json-comments):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre de '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 OMITIR LA DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ util-deprecate):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ util-deprecate' -> 'C : \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.util-deprecate.DELETE '
npm WARN opcional SALTAR DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ wrappy):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre de 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ wrappy' -> 'C: \ Usuarios \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.wrappy.DELETE '
npm WARN opcional SALTAR DEPENDENCIA OPCIONAL: [email protected] (node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ yallist):
npm WARN enoent SALTAR LA DEPENDENCIA OPCIONAL: ENOENT: no existe tal archivo o directorio, cambie el nombre de 'C: \ Users \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules \ yallist' -> 'C: \ Usuarios \ Matheus \ AppData \ Roaming \ npm \ node_modules \ expo-cli \ node_modules \ fsevents \ node_modules.yallist.DELETE '

npm WARN obsoleto [email protected] : la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142
¿por favor, me puedes ayudar? No puedo resolver este problema y no puedo iniciar mi proyecto.

npm WARN obsoleto [email protected] : la solicitud ha quedado obsoleta, consulte # 3142
¿por favor, me puedes ayudar? No puedo resolver este problema y no puedo iniciar mi proyecto.

Yo tampoco

@ liaz98 @TheLitz no es un error, es una advertencia. Si su proyecto no se compilará / comenzará debido a una advertencia de npm, entonces algo está mal con su proyecto y / o entorno. Este no es un problema con la solicitud.

@ liaz98 @TheLitz no es un error, es una advertencia. Si su proyecto no se compilará / comenzará debido a una advertencia de npm, entonces algo está mal con su proyecto y / o entorno. Este no es un problema con la solicitud.

pero cuando intento ejecutar la Expo, no funciona

@TheLitz entonces ese es un problema con Expo, y deberías informarlo en su rastreador de errores. No es nada que pueda o vaya a resolverse en el lado de la solicitud.

@TheLitz entonces ese es un problema con Expo, y deberías informarlo en su rastreador de errores. No es nada que pueda o vaya a resolverse en el lado de la solicitud.

Está bien. Gracias

solicitamos una solicitud futura.

tldr;
¿Qué se supone que debo usar ahora?

@YashKumarVerma usa postman-request

@TheLitz entonces ese es un problema con Expo, y deberías informarlo en su rastreador de errores. No es nada que pueda o vaya a resolverse en el lado de la solicitud.

¿Resuelve este problema ????
npm WARN obsoleto [email protected] : la solicitud ha quedado obsoleta,

Entonces, ¿cuál es la guía sobre la forma alternativa de hacer una solicitud https para mí que es nueva para el desarrollo de back-end con node?

@OluwafemiAdesegha
¿Conseguiste aclarar dónde moverte? ¡Estoy en el mismo bote que tú! :(

Para cualquiera que busque alternativas, mire # 3143 ( @ farhan3040 @OluwafemiAdesegha @iamdesfranco )

@mikeal Recomiendo cerrar este problema;)

@iamdesfranco @ farhan3040 HTTP quedó obsoleto, utilice Gopher o UDP

@mikeal Recomiendo cerrar este problema;)

O mejor, bloquearlo. Básicamente, todo lo que hay que decir se ha dicho en este punto, y las únicas preguntas que se hacen tienden a ser las que ya se han respondido (varias veces).

Franco,

Disculpa por la respuesta tardía. Todavía estoy tratando de ver cuál haría
finalmente vaya con en base a las sugerencias dadas.

El lun, 6 de abril de 2020, 9:12 a.m. Franco Labuschagne [email protected]
escribió:

Entonces, ¿cuál es la guía sobre la forma alternativa de hacer una solicitud https para mí?
que es nuevo en el desarrollo de back-end con node?

¿Conseguiste aclarar dónde moverte? Estoy en el mismo barco
¡como tu! :(

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/request/request/issues/3142#issuecomment-609643295 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AOL4QYXM7V2BUK5LZCS7LDDRLGFH5ANCNFSM4HCP6LRA
.

y las posibles alternativas se refieren a este tema.

¿Dónde encontré las alternativas en esta página?

¿La sugerencia de usar fetch en el navegador + fetch lib para el nodo, o simplemente es una alternativa basada en promesas, etc.?

@TomYeoman La sugerencia es no usar request .

@gcacars Alternativas aquí: https://github.com/request/request/issues/3143

@Richienb gracias. Creo que es importante tener un enlace a esto en el archivo README.

Eliminé la carpeta "node_modules" y el archivo "package-lock.json" y luego ejecuté los siguientes 2 comandos.
npm init
npm install

Y luego, funcionó correctamente.

Los confirmadores que aún están activos intentarán fusionar las correcciones de manera oportuna, aunque sin promesas.

Brillante juego de palabras accidental (?)

npm WARN obsoleto [email protected] : la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142

como solucionar esto ??,

@ anton-bot Sin malware, por favor.

npm WARN obsoleto [email protected] : la solicitud ha quedado obsoleta, consulte # 3142

como solucionar esto ??,

@Amouthinie no hay nada que solucionar, no es un error. NPM le advierte que request está en desuso y usted (o quienquiera que mantenga sus dependencias que a su vez dependen de request ) debería considerar cambiarse a un paquete de mantenimiento activo.

He tenido dos problemas:
1 - sudo apt-get install nodejs npm
Leyendo listas de paquetes ... Hecho
Construyendo árbol de dependencia
Leyendo información de estado ... Hecho
nodejs ya es la versión más nueva (13.13.0-1nodesource1).
No se pudieron instalar algunos paquetes. Esto podría significar que
solicitó una situación imposible o, si está utilizando el
distribución inestable, que algunos paquetes requeridos no fueron
creado o eliminado de "Entrante".
La siguiente información puede ayudar a resolver la situación:

Los siguientes paquetes tienen dependencias no coincidentes:
nodejs: Conflicto: npm
E: Incapaz de solucionar los problemas, mantuvo (mantuvo) los paquetes rotos.

2 - sudo npm install -g @ angular / cli
npm WARN obsoleto [email protected]: la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142
npm ERR! Código EEXIST
npm ERR! enlace simbólico syscall
npm ERR! ruta ../lib/node_modules/@angular/cli/bin/ng
npm ERR! dest / usr / bin / ng
npm ERR! errno -17
npm ERR! EEXIST: el archivo ya existe, enlace simbólico '../lib/node_modules/@angular/cli/bin/ng' -> '/ usr / bin / ng'
npm ERR! El archivo existe: / usr / bin / ng
npm ERR! Elimine el archivo existente e intente nuevamente, o ejecute npm
npm ERR! con --force para sobrescribir archivos de forma imprudente.

npm ERR! Puede encontrar un registro completo de esta ejecución en:
npm ERR! /home/anderson/.npm/_logs/2020-04-17T16_25_56_704Z-debug.log

Soy un usuario de Linux Mint 19.3 Cinnamon, 4.4.8, 5.3.0-46-generic

¿Alguien puede ayudarme?

@LeloCorrea Tu error no está relacionado con request , es un problema con la creación de un enlace simbólico en tu entorno local:

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

@LeloCorrea Tu error no está relacionado con request , es un problema con la creación de un enlace simbólico en tu entorno local:

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

¿Sabes cómo puedo solucionar este problema?

@LeloCorrea Tu error no está relacionado con request , es un problema con la creación de un enlace simbólico en tu entorno local:
npm ERR! EEXIST: file already exists, symlink '../lib/node_modules/@angular/cli/bin/ng' -> '/usr/bin/ng'

¿Sabes cómo puedo solucionar este problema?

No es exactamente el mismo problema, pero la solución puede ser la misma. Deberías empezar aquí:

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

Además, nuevamente, este problema no está relacionado con la solicitud de ninguna manera , debe solicitar ayuda sobre la CLI de Angular en el rastreador de problemas correspondiente.

Entonces, ¿cuál es la alternativa recomendada? ¿Solo usa paquetes http / https?

@RonRofe Estoy usando https://github.com/sindresorhus/got , parece ser un buen sucesor, tiene una guía sobre cómo migrar desde la solicitud .

@RonRofe hay una lista (WIP) de alternativas aquí: https://github.com/request/request/issues/3143

Estoy triste por esto, la solicitud ha sido mi biblioteca de acceso desde que tengo uso de razón.
Solo puedo agradecer al autor y a los colaboradores por el increíble trabajo que han realizado en esto a lo largo de los años, y espero que su próxima aventura sea tan emocionante como esta.
¡Salud!

¿Puede dar recomendaciones de alternativas en su primer comentario adhesivo?

Hola, estoy tratando de crear un nuevo proyecto angular y tengo este error:
/ Instalando paquetes ... npm WARN obsoleto [email protected] : la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142
npm WARN obsoleto [email protected] : Chokidar 2 se romperá en el nodo v14 +. Actualice a chokidar 3 con 15 veces menos dependencias.
npm WARN obsoleto [email protected] : fsevents 1 se interrumpirá en el nodo v14 +. Actualice a fsevents 2 con mejoras masivas.
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! Final inesperado de la entrada JSON al analizar cerca de '... ": {" @ angular / core ":" 5'

npm ERR! Puede encontrar un registro completo de esta ejecución en:
npm ERR! C: \ Users \ dell \ AppData \ Roamingnpm-cache_logs \ 2020-04-21T11_50_16_582Z-debug.log
× Falló la instalación del paquete, ver arriba.
El flujo de trabajo del esquema falló. Véase más arriba.
Podría alguien ayudarme con esto ?

Hola, estoy tratando de crear un nuevo proyecto angular y tengo este error:
/ Instalando paquetes ... npm WARN obsoleto [email protected] : la solicitud ha quedado obsoleta, consulte # 3142
npm WARN obsoleto [email protected] : Chokidar 2 se romperá en el nodo v14 +. Actualice a chokidar 3 con 15 veces menos dependencias.
npm WARN obsoleto [email protected] : fsevents 1 se interrumpirá en el nodo v14 +. Actualice a fsevents 2 con mejoras masivas.
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! Final inesperado de la entrada JSON al analizar cerca de '... ": {" @ angular / core ":" 5'

npm ERR! Puede encontrar un registro completo de esta ejecución en:
npm ERR! C: \ Users \ dell \ AppData \ Roamingnpm-cache_logs \ 2020-04-21T11_50_16_582Z-debug.log
× Falló la instalación del paquete, ver arriba.
El flujo de trabajo del esquema falló. Véase más arriba.
Podría alguien ayudarme con esto ?

Yo también

CREAR mi-proyecto / angular.json (3598 bytes)
CREAR mi-proyecto / paquete.json (1286 bytes)
CREAR mi-proyecto / README.md (1026 bytes)
CREAR mi-proyecto / tsconfig.json (489 bytes)
CREAR mi-proyecto / tslint.json (3125 bytes)
CREAR mi-proyecto / .editorconfig (274 bytes)
CREAR mi-proyecto / .gitignore (631 bytes)
CREAR mi proyecto / lista de navegadores (429 bytes)
CREAR mi-proyecto / karma.conf.js (1022 bytes)
CREAR mi-proyecto / tsconfig.app.json (210 bytes)
CREAR mi-proyecto / tsconfig.spec.json (270 bytes)
CREAR mi-proyecto / src / favicon.ico (948 bytes)
CREAR mi-proyecto / src / index.html (295 bytes)
CREAR mi-proyecto / src / main.ts (372 bytes)
CREAR mi-proyecto / src / polyfills.ts (2835 bytes)
CREAR mi-proyecto / src / styles.css (80 bytes)
CREAR mi-proyecto / src / test.ts (753 bytes)
CREAR mi-proyecto / src / assets / .gitkeep (0 bytes)
CREAR mi-proyecto / src / environment / environment.prod.ts (51 bytes)
CREAR mi-proyecto / src / environment / environment.ts (662 bytes)
CREAR mi-proyecto / src / app / app-routing.module.ts (246 bytes)
CREAR mi-proyecto / src / app / app.module.ts (393 bytes)
CREAR mi-proyecto / src / app / app.component.html (25757 bytes)
CREAR mi-proyecto / src / app / app.component.spec.ts (1071 bytes)
CREAR mi-proyecto / src / app / app.component.ts (214 bytes)
CREAR mi-proyecto / src / app / app.component.css (0 bytes)
CREAR mi-proyecto / e2e / protractor.conf.js (808 bytes)
CREAR mi-proyecto / e2e / tsconfig.json (214 bytes)
CREAR mi-proyecto / e2e / src / app.e2e-spec.ts (643 bytes)
CREAR mi-proyecto / e2e / src / app.po.ts (301 bytes)
/ Instalando paquetes ... npm WARN obsoleto [email protected] : TSLint ha quedado obsoleto en favor de ESLint. Consulte https://github.com/palantir/tslint/issues/4534 para obtener más información.
npm WARN obsoleto [email protected] : la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142
npm WARN obsoleto [email protected] : Actualice a chokidar 3 con 15 veces menos dependencias. Chokidar 2 se romperá en el nodo 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! Final inesperado de la entrada JSON al analizar cerca de '.... 0.1 "," systemjs ":" ^ 0.'

npm ERR! Puede encontrar un registro completo de esta ejecución en:
npm ERR! C: \ Users \ 92306 \ AppData \ Roamingnpm-cache_logs \ 2020-04-21T16_08_05_350Z-debug.log
× Falló la instalación del paquete, ver arriba.
El flujo de trabajo del esquema falló. Véase más arriba.

@ awais0048 @xunyegege su error no tiene nada que ver con la solicitud. Estudie la salida real y le indicará con precisión cuál es el error. Si tiene más problemas con Angular CLI, infórmelo en su rastreador de problemas.

@ awais0048 @xunyegege su error no tiene nada que ver con la solicitud. Estudie la salida real y le indicará con precisión cuál es el error. Si tiene más problemas con Angular CLI, infórmelo en su rastreador de problemas.

Intenté actualizar NPM y el nodo pero no tengo ni idea. Si alguien encuentra una solución, ¿puede decirme por favor?

@ANadjia nuevamente, el error no tiene nada que ver con este paquete. Debe solicitar en el rastreador Angular CLI.

Hola, Instalando paquetes ... npm WARN obsoleto [email protected] : la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142 npm ERR! Final inesperado de la entrada JSON al analizar cerca de '... ZXQ4dst \ n4bcYaiOdlbvh'
cuando creo un nuevo proyecto
alguna sugerencia

@mohamedelsoufi, esto es un problema con su entorno o proyecto, no con este paquete. NPM solo le advierte que este paquete está obsoleto.

@milette
Es una buena idea mantener este hilo en funcionamiento como recordatorio de las consecuencias de desaprobar un paquete utilizado en el 99% de los proyectos en el mundo.

@ anton-bot En realidad, un recordatorio de cuántas personas no utilizan RTFM.

@csvan y dicen que no es su problema también
De cualquier manera, finalmente conseguí que las cosas funcionaran para mí.
Así que básicamente :
1 / i downgrade a la versión 10.13.0 del nodo js;
2 / eliminé manualmente la carpeta npm_cache
3 / ejecutar npm install;
y por arte de magia funcionó

@ANadjia es bueno escuchar!

El reemplazo sugerido no está claro. ¿Qué deberíamos usar en su lugar?

@johnworthley lo que sea que funcione para ti. Hay una lista de alternativas sugeridas aquí: https://github.com/request/request/issues/3143

@johnworthley lo que sea que funcione para ti. Hay una lista de alternativas sugeridas aquí: # 3143

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

¿Podemos seguir usando esta biblioteca incluso si está obsoleta? Por favor avise a @mikeal

¿Podemos seguir usando esta biblioteca incluso si está obsoleta? por favor avise

@DokurOmkar Sí. No hay nada que le impida utilizar la biblioteca. Es simplemente una advertencia. Sin embargo, está obsoleto por una razón: existen bibliotecas mejores y más modernas. Lea este hilo y encontrará un enlace a una lista de bibliotecas alternativas.

no puedo crear un nuevo proyecto angular
está fallando debido a -
npm WARN obsoleto [email protected] : la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142

@adibhosale ¿Tienes más información? ¿Cuáles son los otros mensajes de la consola que está viendo?

@adibhosale no, no está fallando por eso. Si es así, entonces es un problema con angular-cli, no con este paquete. Verifique el resto de la salida del registro.

@ anton-bot
Responder a -> @adibhosale ¿Tienes más información? ¿Cuáles son los otros mensajes de la consola que está viendo?

Este es el error que recibo al crear un nuevo proyecto angular.

Instalando paquetes ... npm WARN obsoleto [email protected] : TSLint ha quedado obsoleto en favor de ESLint. Consulte https://github.com/palantir/tslint/issues/4534 para obtener más información.
npm WARN obsoleto [email protected] : la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142
npm WARN obsoleto [email protected] : Chokidar 2 se romperá en el nodo v14 +. Actualice a chokidar 3 con 15 veces menos dependencias.
npm WARN obsoleto [email protected] : fsevents 1 se romperá en el nodo v14 + y podría estar usando binarios inseguros. Actualice a 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 llamado!

npm ERR! Informe este error en:
npm ERR! https://npm.community

npm ERR! Puede encontrar un registro completo de esta ejecución en:
npm ERR! C: \ Users \ adibh \ AppData \ Roamingnpm-cache_logs \ 2020-05-05T08_46_31_829Z-debug.log
× Falló la instalación del paquete, ver arriba.
El flujo de trabajo del esquema falló. Véase más arriba.

Estoy confundido acerca de por qué tantos usuarios informan detalles totalmente irrelevantes sobre este problema.

Parece que la mayoría de los usuarios que vinieron aquí no tienen idea de lo que están haciendo, probablemente ni siquiera entienden lo que significa la palabra obsoleta.

pero el último mensaje publicado aquí, hay más de un mensaje de desactivación, ¿por qué eligen informar sobre este problema? porque algunos usuarios ya lo hicieron y simplemente continúan?

y el último bit de ese mensaje específico, dice específicamente que el error de npm debe informarse a npm.community.

Creo que los mantenedores aquí deberían eliminar todos los elementos de discusión no relevantes para solicitar la desaprobación y bloquear las discusiones aquí.

tal vez el mensaje de desaprobación del paquete de solicitudes debería cambiarse a un enlace, en lugar de un problema, como lo hacen los paquetes lydell / urix y lydell / resolve-url, por lo que la avalancha de publicaciones irrelevantes no aparece aquí.

@glensc ¿Quién

@glensc estamos informando sobre este problema en particular porque en el momento de la instalación angular / CLI se nos proporciona el enlace a este problema.

Gracias :-)

Si dice WARN, significa que no es un ERR. Solo algunos hechos.

@adibhosale no, recibe una advertencia de NPM que tiene un enlace a este problema de github, entre MUCHOS otros enlaces en la misma salida de registro. La advertencia no tiene nada que ver con la falla, debe leer el registro con más atención. Establece 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

y esa es la razón por la que falla la instalación. Debe hacer su debida diligencia y averiguar qué causa esto antes de informar un problema en un paquete que no tiene absolutamente nada que ver con él.

@ anton-bot sigues diciendo eso. ¿Tiene algo constructivo que aportar o todavía está aquí para hacer trolls?

@csvan @leoskyrocker @glensc Me disculpo por iniciar esto. Estaré cuidando en el futuro. Gracias :-)

cómo solucionar este problema
no puedo crear un proyecto angular
asunto

////////

obsoleta [email protected] : la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142
npm WARN checkPermissions Falta el acceso de escritura a / usr / local / lib / node_modules
npm ERR! código EACCES
npm ERR! acceso syscall
npm ERR! ruta / usr / local / lib / node_modules
npm ERR! errno -13
npm ERR! Error: EACCES: permiso denegado, acceso '/ usr / local / lib / node_modules'
npm ERR! [Error: EACCES: permiso denegado, acceso '/ usr / local / lib / node_modules'] {
npm ERR! errno: -13,
npm ERR! código: 'EACCES',
npm ERR! syscall: 'acceso',
npm ERR! ruta: '/ usr / local / lib / node_modules'
npm ERR! }
npm ERR!
npm ERR! La operación fue rechazada por su sistema operativo.
npm ERR! Es probable que no tenga los permisos para acceder a este archivo como usuario actual
npm ERR!
npm ERR! Si cree que esto podría ser un problema de permisos, vuelva a verificar el
npm ERR! permisos del archivo y los directorios que lo contienen, o intente ejecutar
npm ERR! el comando nuevamente como root / administrador.

npm ERR! Puede encontrar un registro completo de esta ejecución en:
npm ERR! /Users/vivek/.npm/_logs/2020-05-05T11_48_34_569Z-debug.log

@ vivek08011991 la salida del registro explica lo que debe hacer. Este es un problema al intentar instalar angular globalmente sin usar sudo . No tiene nada que ver con este paquete.

Hey hombre, esto es una mierda de hablar, no importa,
te diré la solución
lo intenté 3 días y luego lo conseguí
primero: npm install npm
seconde: desinstalación de npm --save react-native-cli
finalmente: npm install -g @ angular / cli

Hey hombre, esto es una mierda de hablar, no importa,
te diré la solución
lo intenté 3 días y luego lo conseguí
primero: npm install npm
seconde: desinstalación de npm --save react-native-cli
finalmente: npm install -g @ angular / cli

Hombre, tenías razón alhamdou lil allah. ¿Por qué reaccionar cli está causando el problema? ¿Hay algunas prácticas de competencia desagradables allí? gracias amigo

por favor, preste atención a que esto es request módulo de seguimiento de problemas, no angular .

¿Alguien puede decirme la alternativa a request ?

Estoy leyendo esto y prefiero la API simplista de request :

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

@dolanmiu Seguro. Cualquiera que haya leído el hilo en el que acaba de publicar (o incluso lo haya buscado _alternative_) podría decirle que hay una lista de alternativas en https://github.com/request/request/issues/3143.

@dolanmiu @ root / request es principalmente un reemplazo

@Richienb entre postman-request (también un reemplazo

@ anton-bot Definitivamente @ root / request.

He estado usando request por un tiempo y estoy de acuerdo con mikeal. Los módulos nativos de Node se han desarrollado a lo largo del tiempo para que coincidan con este módulo request , por lo que ya no hay ninguna razón para usarlo, aparte de corregir repetidamente el código cuando llegó una nueva versión de request fuera.

request quedará escrito para siempre en las piedras de la historia; node ha crecido. Este es el momento en el que debemos dejar pasar algunas cosas. request siempre ha sido un pionero en características innovadoras, y sentiré que sin request , el desarrollo de nodos no habría sido tan bueno.

Cuando era un programador joven, me encantaba usar este paquete, pero también sé que para mejorar y crear programas aún mejores, uno no debe quedarse en el pasado por más tiempo.

Cuando era un programador joven, me encantaba usar este paquete

Eso me hizo reír. Como joven programador, usé Commodore BASIC. : smiley:

@darkRaspberry :

  1. lea su informe de error hasta el final, no solo la primera línea, está escrito claramente cuál es el error e incluso una sugerencia de qué hacer. claramente no ha leído más allá de la primera línea.
  2. ¿Buscaste en Google tu error?
  3. lea las discusiones anteriores y explique por qué publica esto aquí, su informe de problemas no tiene nada que ver con el módulo de solicitudes.

simplemente desactive su antivirus, no obtendrá ningún error
Gracias !!!

@glensc Reinstalé completamente mi terminal para eliminar cualquier otra versión del nodo y luego probé "sudo"
Y funcionó.
Estoy usando la versión de nodo de nodejs usando curl para agregar node js en mi PPA.

y aquí funcionó
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

Esto me emocionó. Y: reverencia: ¡a todos los contribuyentes!

image

@ sudarsan2017 Ese error no está relacionado con request de ninguna manera

¡Hola! chicos pasan por el mismo problema en Windows y lo resolví usando el comando

npm instalar [email protected]

Espero que el tuyo esté bien.

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

¿Cómo lo soluciono?

@ aman78600 No hay forma de solucionarlo.

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

@ aman78600 No necesita reparación. Es solo una advertencia de que request has been deprecated .

Su NPM dice que venga aquí en busca de alternativas, pero no las veo.

Su NPM dice que venga aquí en busca de alternativas, pero no las veo.

@skeddles Si hubiera presionado Control-F y buscado alternatives , habría encontrado el enlace a https://github.com/request/request/issues/3143.

No puedo instalar vue-cli desde este comando npm install -g @ vue / cli, muestra el mensaje: npm WARN obsoleto [email protected] : la solicitud ha sido obsoleta

@somnangrom Esto no puede ser cierto, estoy seguro de que hay otros mensajes en la consola y no solo en esta línea.

Realmente quería agradecerles mucho por trabajar en este paquete. Me ha ayudado mucho en mis proyectos. Razones totalmente comprensibles por las que se detiene el soporte.

Hicieron un trabajo increíble, ¡deberían estar orgullosos!

🤝

No puedo instalar la última versión de Angular CLI.
Versión de Nodejs de 64 bits: 12.18.1
versión npm: 6.13.6
Cuando ejecuto npm install -g @ angular / cli @ latest para instalar la última versión de Angular CLI, me da la siguiente advertencia de error
npm WARN obsoleto [email protected] : la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142

La instalación se atasca con el mensaje: postinstall: sill install executeActions
Ayúdame a resolver este problema

No puedo instalar la última versión de Angular CLI.
He instalado Nodejs en mi computadora portátil con Windows 10 Pro
Versión de Nodejs de 64 bits: 12.18.1versión npm: 6.13.6
Cuando ejecuto npm install -g @ angular / cli @ latest para instalar la última versión de Angular CLI, me da la siguiente advertencia de error
npm WARN obsoleto [email protected] : la solicitud ha quedado obsoleta, consulte # 3142

La instalación se atasca con el mensaje: postinstall: sill install executeActions
Ayúdame a resolver este problema

@anjaikr y @ aman78600 refieren https://github.com/angular/angular-cli/wiki/stories-1.0-update para instalar la última versión espero que ayude

npm install -g json-server no funciona, ¿qué debo hacer?

Todavía podemos usarlo para acciones básicas, ¿verdad?

Recibo un error al instalar angular 5, intenté instalar pero muestra que la solicitud ha sido eliminada ... ¿qué debo hacer?

@mikeal Para que quede claro, ¿tiene la intención de que bent reemplace request ?

Hola,

Alguien sabe cuál es el problema:
npm i -g servidor json
npm WARN obsoleto [email protected] : la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142
npm WARN obsoleto [email protected] : esta biblioteca ya no es compatible

Gracias.

Una de las razones más tontas que he escuchado para la depreciación. Imagínese si Google y Microsoft sacaran todos sus productos de los estantes porque es "mucho más difícil que las nuevas bibliotecas que realizan tareas similares obtengan adopción" y porque "ahora se está produciendo una transición en el ecosistema a estos patrones". Completamente ridículo.

image

En primer lugar, muestre mi respeto por este repositorio, sin embargo, para ser honesto, lo que dijo @cypheron tenía sentido.

@ Wenjie-Shao No tiene ningún sentido, me temo. Sin el aviso de obsolescencia, incluso más personas descargarían y usarían esta biblioteca sin darse cuenta de que está desactualizada. @mikeal ha

Solo estoy tratando de abrirme paso a tientas a través del tutorial para configurar surge.sh.

Parece que ustedes tienen muchas cosas aquí. ¿Me arruinará aquí en el nuevo futuro si simplemente ignoro las advertencias y me voy?

Una de las razones más tontas que he escuchado para la depreciación. Imagínese si Google y Microsoft sacaran todos sus productos de los estantes porque es "mucho más difícil que las nuevas bibliotecas que realizan tareas similares obtengan adopción" y porque "ahora se está produciendo una transición en el ecosistema a estos patrones". Completamente ridículo.

Pero lo han hecho. Y a menudo. Hay muchos, muchos productos de estos gigantes del software que ya no existen o que actualmente están en desuso y no reciben ninguna actualización. ¿Has oído hablar de, digamos, Windows 95 o FoxPro? Cada proyecto de software eventualmente llegará y terminará por una razón u otra. Y los autores de Request tampoco lo están sacando de los estantes, están deteniendo nuevos desarrollos. Las correcciones de errores críticos se seguirán produciendo durante un tiempo y, si su proyecto depende de ello, no habrá problemas. Aún puedes seguir usándolo.

Pero si comienza un nuevo proyecto, existen alternativas mejores y más modernas. El lenguaje ha evolucionado, hay mejores formas de hacer las mismas cosas ahora, pero Request no puede seguir el ritmo porque necesita los proyectos heredados para trabajar con él. Para proyectos nuevos, es subóptimo.

Entonces esta decisión tiene mucho sentido para mí. Deje Request donde está para que los proyectos heredados puedan seguir usándolo, pero para nuevos proyectos, recomiende nuevas bibliotecas.

¿Hay alguna razón específica por la que alguien usaría la solicitud en lugar de axios?

¿Hay alguna razón específica por la que alguien usaría la solicitud en lugar de axios?

Seguro. La parte superior de mi cabeza:

  • Estás acostumbrado o tienes mucha experiencia con él.
  • Tu proyecto ya lo usa en todas partes. Cambiarlo todo llevaría semanas, si no meses, de reescritura de código.
  • Las pautas de codificación de la empresa / proyecto exigen esta biblioteca (o solo permiten bibliotecas con ciertos requisitos de "madurez")
  • Una biblioteca de terceros lo requiere (y tal vez incluso requiera que lo use cuando trabaja con la biblioteca). Puntos extra si la biblioteca no tiene alternativas.
  • Eres un estudiante y el curso que estás tomando enseña explícitamente sobre la solicitud y lo tiene en los exámenes / tareas

En esencia, todas estas son variaciones del mismo tema: debe trabajar con algunas cosas heredadas que aún no se han puesto al día con las últimas tendencias. Esto tiende a suceder con bastante regularidad en la vida real.

npm WARN obsoleto [email protected] : la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142
npm WARN obsoleto @ hapi / [email protected] : joi deja la organización @hapi y regresa a 'joi' (https://github.com/sideway/joi/issues/2411)
npm WARN obsoleto @ hapi / [email protected] : esta versión ha quedado obsoleta y ya no se admite ni se mantiene
npm WARN obsoleto @ hapi / [email protected] : esta versión ha quedado obsoleta y ya no se admite ni se mantiene
npm WARN obsoleto @ hapi / [email protected] : esta versión ha quedado obsoleta y ya no se admite ni se mantiene
npm WARN obsoleto @ hapi / [email protected] : esta versión ha quedado obsoleta y ya no se admite ni se mantiene
npm WARN obsoleto [email protected] : esta biblioteca ya no es compatible
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 se romperá en el nodo v14 +. Actualice a chokidar 3 con 15 veces menos dependencias.
npm WARN obsoleto [email protected] : fsevents 1 se romperá en el nodo v14 + y podría estar usando binarios inseguros. Actualice a fsevents 2.

POR QUÉ ???? TODA MI INSTALACIÓN GLOBAL DE NPM SIEMPRE ME ADVERTEN QUE ESTÁ DESAPARECIDA ?? CÓMO ARREGLAR ESTO

TRATO DE DESINSTALAR NODEJS
O
ACTUALIZANDO NPM
PERO NO FUNCIONA
POR FAVOR, AYÚDAME

ESTÁ DESPRECIADO.
NO PUEDE ARREGLAR ESTO.
IGNORAR LA ADVERTENCIA.

O reescribe tu código para que no use Request.

@acatzk

Tratar

npm install -s (o --silent)
o

npm install -q (o --quiet)

para silenciar las advertencias

Este hilo es el mejor.

Hola. Soy nuevo en las API. Estaba intentando instalar el paquete de solicitud y decía que ahora está obsoleto. Traté de buscarlo y ver qué está pasando, pero agradecería que alguien me explicara qué puedo hacer ahora. ¿Significa esto que el paquete de solicitud ya no se puede utilizar? ¿Qué otro paquete puedo usar para hacer el mismo trabajo?

@ mohammed3736 No, todavía se puede utilizar. Pero no se actualizará. No obtendrá nuevas funciones. Es posible que tenga algunas correcciones de errores por un tiempo, pero no por mucho tiempo. Y la advertencia siempre estará ahí. Básicamente, están abandonando el proyecto. Si desea realizar algún cambio, deberá hacerlo usted mismo. Después de todo, todo el código fuente para la solicitud todavía está disponible. Puedes hacer tu propio tenedor y hacer lo que sea con él.

Si está escribiendo un nuevo proyecto, mejor pruebe con otra biblioteca más moderna. Por ejemplo, usamos Axios, pero estoy seguro de que hay otros.

Voy a hacer la siguiente pregunta en mis entrevistas ahora en lugar de 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 Eso es fácil, la respuesta es: "Hago clic en el enlace, no leo nada, pero voy al final del hilo y publico la misma pregunta que todos los demás".

¿Consigo el trabajo?

@ anton-bot Eso es fácil, la respuesta es: "Hago clic en el enlace, no leo nada, pero voy al final del hilo y publico la misma pregunta que todos los demás".

¿Consigo el trabajo?

La razón por la que preguntaba es porque sigo recibiendo 401 en el registro de mi consola. Y el módulo de solicitud no me funciona. Estoy tratando de usar la API de bitcoinaverage y de https://any-api.com/ y ninguno de ellos funcionaba. Cuando entro en localhost3000, el html funciona y obtengo la página, pero cuando presiono el botón para obtener el resultado, mi consola se bloquea. El registro de mi consola dice que la aplicación se bloqueó o 401 para el código de estado y en el navegador. También tenga en cuenta que ninguno de mis proxies está habilitado. Intenté todo, pero sigo recibiendo errores. SI puedes ayudarme te lo agradecería.

@ mohammed3736 : este es el lugar equivocado para preguntar. Además, estoy 99,99% seguro de que no es la biblioteca de solicitudes la culpable. Hay un error en tu programa y lo hiciste tú mismo. También tendrás que resolverlo tú mismo. Si aún necesita ayuda, intente preguntar en StackOverflow, pero incluya el código que no funciona. Lo mejor de todo: intente hacer el programa más pequeño posible que falle y muestre ese código fuente.

También vine aquí para hacer una pregunta pero ... ¿qué pasa con todos los ataques racistas aquí? ustedes son increíbles.

Y sí, todavía no tengo idea de por qué mi código no funciona. El único error en la consola me trae aquí.

Comprueba tu privilegio y diviértete

También vine aquí para hacer una pregunta pero ... ¿qué pasa con todos los ataques racistas aquí? ustedes son increíbles.

Y sí, todavía no tengo idea de por qué mi código no funciona. El único error en la consola me trae aquí.

Comprueba tu privilegio y diviértete

¿A qué ataques racistas te refieres? Eso suena muy mal

Se observó el mismo problema. Por favor ayude si alguien sabe cómo resolver

[email protected] : la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142

@ HaseebAhmed49 el paquete npm de "solicitud" que está en desuso no es un problema per se. el mensaje es para los desarrolladores de proyectos de bibliotecas.

No se preocupe por eso. Mucha gente en github me dijo que estaba bien. Eso
básicamente significa que el paquete no tendrá nuevas funciones agregadas
a él y no se actualizará, pero aún así está perfectamente bien para
usar. Lo usé y estuvo bien.

El lunes, 14 de septiembre de 2020 a las 11:57 p.m. Elan Ruusamäe [email protected]
escribió:

>
>

@ HaseebAhmed49 https://github.com/HaseebAhmed49 la "solicitud" npm
que el paquete esté en desuso no es un problema en sí mismo. el mensaje es a la biblioteca
desarrolladores de proyectos.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/request/request/issues/3142#issuecomment-692279572 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AQFTBJ255VRYJW4VMUFQQ23SFZYSZANCNFSM4HCP6LRA
.

pero todavía está perfectamente bien de usar

Realmente no. Puede que funcione _por ahora_, pero nunca debe tener una dependencia explícita de un paquete que no recibirá más errores y correcciones de seguridad. Estás poniendo tu aplicación (y usuarios) en un riesgo significativo de rotura repentina y fugas de seguridad cuando ese paquete finalmente _deja_ de funcionar (lo cual es casi seguro que lo hará). Esto es especialmente cierto para un paquete como request que proporciona algo tan crucial y sensible como realizar solicitudes de red.

Una advertencia de desaprobación es un aviso serio para comenzar a migrar a otro lugar. Ya se han mencionado (y repetido) varias alternativas en este hilo.

Hola a todos, también tuve estos problemas obsoletos
así que lo que hice fue desinstalar nodejs y descargar las últimas funciones de nodejs
que es 14.10.1 Últimas características actuales
https://nodejs.org/en/

y borra todos esos npm globales instalados que tienes en la computadora

y eso es...

todos los obsoletos se han ido ...

@acatzk wtf lmao

Esta biblioteca está obsoleta . Si hay un error, no se hará nada para solucionarlo. Si hay un problema de seguridad, no se hará nada para solucionarlo.

No deberías usar esto.

@davwheat gracias

¿Cuáles son las alternativas de este módulo de solicitud?

Cosas que podríamos hacer - ¡discuta y sea voluntario!

  • [] actualiza el archivo Léame con el estado actual del proyecto
  • [] actualizar la canalización de publicaciones de ci @mikeal
  • [] proporciona un documento con orientación sobre request alternativas # 3143
  • [] agregue un mensaje de advertencia al instalar el paquete para usar otro paquete y hacer referencia al documento
  • [] elige una fecha para suspender el apoyo (voto 6 meses, pero 12 es probablemente más amigable)
  • [] cerrar todas las solicitudes de funciones y prs de funciones
  • [] revisar y fusionar las correcciones de errores relevantes
  • [] agregue el problema de github y las plantillas de relaciones públicas que explican que las características no se fusionarán
  • [] desaprueba la próxima versión principal ( 3.x ) para que los proyectos en mantenimiento activo reciban una advertencia, pero los proyectos más antiguos continúan como de costumbre

¿Alguna actualización de quién está haciendo qué en este momento?

Para aquellos que buscan una alternativa sólida y compatible con Google (aparte de las que se encuentran en https://github.com/request/request/issues/3143), les recomiendo https://github.com/googleapis/gaxios. Lo he estado usando en un proyecto reciente y es excelente hasta ahora.

¿Cuales son las alternativas? Tu página npm dice For more information about why request is deprecated and possible alternatives refer to {the link to this page}

3143

Registro npm WARN Utilizando datos obsoletos de https://registry.npmjs.org/ debido a un error de solicitud durante la revalidación.
npm WARN obsoleto [email protected] : la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142

@thbestforyourbizdeployment sí.

Gracias.

¿me puedes ayudar?

npm WARN obsoleto [email protected]: la solicitud ha quedado obsoleta, consulte https://github.com/request/request/issues/3142
npm WARN obsoleto [email protected]: esta biblioteca ya no es compatible
npm ERR! código EEXIST
npm ERR! enlace simbólico syscall
npm ERR! ruta ../lib/node_modules/firebase-tools/lib/bin/firebase.js
npm ERR! dest / usr / local / bin / firebase
npm ERR! errno -17
npm ERR! EEXIST: el archivo ya existe, enlace simbólico '../lib/node_modules/firebase-tools/lib/bin/firebase.js' -> '/ usr / local / bin / firebase'
npm ERR! El archivo existe: / usr / local / bin / firebase
npm ERR! Elimine el archivo existente e intente nuevamente, o ejecute npm
npm ERR! con --force para sobrescribir archivos de forma imprudente.

npm ERR! Puede encontrar un registro completo de esta ejecución en:
npm ERR! /Users/bahar/.npm/_logs/2020-11-18T17_07_43_310Z-debug.log

@baharozcelik No hay nada en lo que pueda ayudarlo.

Leer. Asunto.

sudo npm install --global gulp-cli
prueba así

¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

jasonxia23 picture jasonxia23  ·  3Comentarios

pixarfilmz112 picture pixarfilmz112  ·  3Comentarios

mlegenhausen picture mlegenhausen  ·  4Comentarios

ghost picture ghost  ·  3Comentarios

IgorDePaula picture IgorDePaula  ·  3Comentarios