Je soutiens pleinement cela, je pense qu'un message d'avertissement et/ou la dépréciation des nouvelles versions est de mise.

Quant au changement de processus et de directives, cela facilite grandement mon travail 👌

Très bien dit @mikeal. J'épingle ce problème pour gagner en visibilité.

Choses que nous pourrions faire - s'il vous plaît discuter et faire du bénévolat!

• [ ] mettre à jour le fichier readme avec l'état actuel du projet
• [ ] mettre à jour le pipeline de publication ci @mikeal
• [ ] fournit un document contenant des conseils sur les alternatives request https://github.com/request/request/issues/3143
• [ ] ajoute un message d'avertissement à l'installation du package pour utiliser un autre package et référencer la doc
• [ ] choisissez une date pour arrêter le support (je vote 6 mois, mais 12 est probablement plus convivial)
• [ ] ferme toutes les demandes de fonctionnalités et les propositions de fonctionnalités
• [ ] réviser et fusionner les corrections de bogues pertinentes
• [ ] ajouter un problème github et des modèles pr expliquant que les fonctionnalités ne seront pas fusionnées
• [ ] désapprouve la prochaine version majeure ( 3.x ) afin que le projet en maintenance active reçoive un avertissement, mais les projets plus anciens continuent comme d'habitude

Cela a beaucoup de sens ! J'adopterai lentement cette politique pour la famille request-promise . Bravo à vos contributions importantes à l'écosystème des nœuds !

déprécier le dernier package npm et les déprécier automatiquement lors de la publication

Veuillez faire attention à la dépréciation. Comme Mikael l'a écrit ci-dessus, il y a 41K modules en fonction de request . Beaucoup de ces modules sont utiles dans l'état actuel et fonctionnent bien pour leurs utilisateurs, mais leurs responsables n'auront peut-être pas le temps de retravailler ces modules pour utiliser autre chose que request . En désapprouvant request au moment de l'installation, vous désapprouvez fondamentalement une grande partie de l'écosystème du module npm.

Selon moi, le mode maintenance n'est pas la même chose que la dépréciation.

• Mode maintenance = nous allons corriger les bugs et les failles de sécurité afin que vous puissiez continuer à utiliser ce package.
• Deprecation = personne ne devrait plus utiliser ce paquet. Cela se produit généralement lorsque le module est abandonné et ne recevra aucun autre bogue ou correctif de sécurité.

Je t'entends. Le texte intégral

déprécier le dernier package npm et les déprécier automatiquement lors de la publication via ci __ (peut-être après l'arrêt du support ?)__

Je pense que nous devrions éventuellement déprécier request parce que je ne veux pas que de nouveaux projets l'utilisent.
J'ai essayé de trier les problèmes et de les réduire à une liste que nous pouvons résoudre, mais il y a des bogues que nous ne pouvons pas corriger sans un changement radical. Par conséquent, ils ne seront pas corrigés et les nouveaux utilisateurs auront des problèmes.

Par exemple, les redirections suivantes perdent les corps de requête et les cookies, et l'analyse d'URL pour supprimer les chemins relatifs sont deux bogues, mais je ne suis pas sûr qu'ils soient jamais corrigés.

Peut-être que la dépréciation n'est pas la bonne réponse, mais je ne sais pas comment aborder cela autrement.

Cela a-t-il du sens?

Remplaçons simplement la version majeure lorsque nous la déprécions. De cette façon, la plupart des personnes en fonction du projet ne verront pas cette erreur jusqu'à ce qu'elles essaient de passer à une nouvelle version majeure, ce qui signifie qu'elles la développent activement et devraient vraiment chercher une alternative.

Je suis fier d'avoir fait partie de l'histoire de request . Je vais également vérifier bent , ça a l'air intéressant, et _small_, qui est plus important pour moi ces jours-ci.

Nous allons devoir supprimer les collaborateurs inactifs et appliquer 2fa, car les droits de validation deviendront effectivement des droits de publication npm.

Très bien pour me retirer.

Je pense que nous devrions éventuellement déprécier la demande car je ne veux pas que de nouveaux projets l'utilisent.

En tant que programmeur qui est TRÈS reconnaissant pour le module et qui l'utilise tout le temps, JE VEUX l'utiliser sur de nouveaux projets.

Cette décision a dû être très dure à prendre mais est louable à l'extrême. Bien fait.

Je suis fier d'avoir utilisé cet outil incroyable. Cela a forcé la communauté à s'améliorer. ??
Si vous avez besoin d'aide pour l'entretenir n'hésitez pas à me contacter.

Bien que je respecte votre décision, je vous demanderais de considérer dans quelle mesure le code du monde réel, de la production, repose sur la demande actuellement. C'est bien plus que ce que même les statistiques du NPM peuvent vous dire. Je comprends parfaitement vouloir passer à une nouvelle chose et faire quelque chose d'une manière nouvelle et plus intéressante... c'est l'écosystème JavaScript après tout, il faut chasser la nouvelle chose. Mais s'il vous plaît, considérez le temps et l'argent que vous coûteriez aux organisations professionnelles d'ingénierie en dépréciant en gros la demande. Si vous voulez le laisser en mode maintenance, c'est bien, mais comprenez que beaucoup de gens n'ont absolument aucune raison pratique de changer de bibliothèque. Forcer les gens à changer à cause de l'idéologie va conduire à la frustration.

Quoi qu'il en soit, merci pour le travail acharné que tout le monde a consacré à cette bibliothèque.

Je me demande quelle bibliothèque pourrait être considérée comme moderne et recommandée maintenant. Superagent est principalement en mode maintenance pour le moment, axios pas trop actif du tout.

Juste un petit mot pour vous remercier (et tous les autres contributeurs) pour tout le travail acharné au fil des ans sur ce module ; c'était l'un des premiers que j'ai utilisé lorsque j'ai commencé avec Node, il aura donc toujours une place spéciale dans mon cœur.

Remplaçons simplement la version majeure lorsque nous la déprécions. De cette façon, la plupart des personnes en fonction du projet ne verront pas cette erreur jusqu'à ce qu'elles essaient de passer à une nouvelle version majeure, ce qui signifie qu'elles la développent activement et devraient vraiment chercher une alternative.

Je pense que c'est toujours une solution viable pour la mention ci-dessus.

@kibertoad On dirait que @mikeal travaille sur https://github.com/mikeal/bent . J'utilise https://github.com/sindresorhus/got depuis de nombreuses années et il est bien pris en charge et évolue.

Avec tout ce discours et la possibilité qu'il soit déprécié, je pense qu'il doit y avoir une mention égale d'un module de remplacement de maturité actuel, d'utilité parallèle. Nous ne pouvons pas simplement annoncer sa fin et ne rien suggérer ensuite, ou un remplacement de beaucoup moins de maturité et de confiance. La demande est utilisée dans des applications sérieuses. Pourquoi est-ce important ? Parce que malgré tous ses « modèles dépassés en son cœur », il fonctionne au quotidien, pour des milliers de personnes. Il ne s'agit pas du monde parfait mais du monde réel. Quel est le remplacement réel, de confiance, le jour où la demande est mise en mode maintenance ou est obsolète ? C'est un impératif.

Vous pouvez trouver cette discussion ici https://github.com/request/request/issues/3143

Vous pouvez trouver un plan de travail actuel (dont les commentaires directs sont les bienvenus) ici https://github.com/request/request/issues/3142#issuecomment -478303334

Merci pour votre travail sur request !

Les modèles au cœur de la demande sont obsolètes.

Les modèles changent tous les quelques mois et années, en particulier dans la communauté JavaScript. Les raisons pour lesquelles request a été créé à l'origine ne sont-elles pas toujours valables aujourd'hui ?

request a 10 ans de commits, de stabilité et de tests. Pourquoi repartir de zéro ? N'est-ce pas simplement ajouter plus de "fatigue JavaScript", résultant en plus de bibliothèques faisant la même chose - des requêtes HTTP ?

Il est triste de voir disparaître une bibliothèque aussi importante et historique dans l'histoire de Node, car les flux et les rappels ne sont plus fantaisistes en 2019.

Je ne pense pas qu'il soit vraiment nécessaire de déprécier la bibliothèque, elle existe depuis environ 10 ans maintenant, elle est utilisée dans de nombreux endroits et est en fait assez stable, et à la fin. tout ce qu'il fait, c'est faire des requêtes HTTP, de quoi d'autre la bibliothèque aurait-elle besoin ? Support pour la mode JS du mois ? ??

Les commiters qui sont encore actifs essaieront de fusionner les correctifs en temps opportun, sans promesse cependant .

ba-dum-chhh ! ??

Il s'agit d'une dépréciation responsable. Bien communiqué, avec un plan à suivre. Je pense que d'autres mainteneurs d'OSS peuvent considérer cela comme une norme à viser.

C'est bien mieux que d'oublier un paquet et de laisser des personnes au hasard (qui peuvent injecter des portes dérobées dans le code) en tant que mainteneurs pour prendre le relais lorsque vous ne vous en souciez plus.

La demande était un excellent package, et nous vous remercions énormément pour vos contributions au premier écosystème de nœuds. Vous avez raison dans votre évaluation que le style de rappel n'est plus du JavaScript idiomatique, et il existe d'autres packages comme fetch qui reflètent les normes WHATWG.

@stcktrce Exactement, la bibliothèque n'a besoin de rien d'autre, elle fonctionne telle quelle. Mais il y a eu des améliorations majeures dans l'ensemble de l'écosystème. Déprécier la bibliothèque ne fait que marquer l'opportunité pour les autres de vérifier des bibliothèques nouvelles et plus modernes au lieu de simplement se fier aux plus populaires.

@mikeal merci pour tous vos efforts dans la bibliothèque ( r2 aussi) et l'écosystème. Aussi, pour avoir établi cette priorité d'une dépréciation bien pensée et planifiée dans l'écosystème.

Remplaçons simplement la version majeure lorsque nous la déprécions. De cette façon, la plupart des personnes en fonction du projet ne verront pas cette erreur jusqu'à ce qu'elles essaient de passer à une nouvelle version majeure, ce qui signifie qu'elles la développent activement et devraient vraiment chercher une alternative.

@mikeal Je ne pense pas que ce soit une bonne idée.

Le problème est que la plupart des remplacements sont de qualité inférieure à la demande. Je viens de déménager à request depuis axios environ une semaine.

Axios a des bogues persistants sur plusieurs années autour de la prise en charge des proxy, de la modification des agents https et des exceptions de promesse non gérées. Vous ne les découvrirez qu'après avoir investi massivement dans axios.

Pour les nouveaux utilisateurs, axios semble superficiellement aussi bon que la demande (nombre d'utilisateurs similaire, promesses par conception, etc.)

Merci pour request :)

Si quelqu'un recherche une bibliothèque HTTP minimale basée sur des promesses avec des filtres enfichables et une bonne prise en charge des flux, vous pouvez consulter httplease . Nous l'utilisons depuis quelques années en production.

J'adore le module de demande. Merci beaucoup.
Vous voulez dire que la demande est trop focalisée pour empêcher la sortie d'un autre nouveau module ?

S'il existe des bogues spécifiques dans des fonctionnalités comparables dans d'autres bibliothèques, j'aimerais les identifier spécifiquement. La prise en charge du proxy est une fonctionnalité complexe et avoir un scénario de test qui demande des réussites mais que d'autres bibliothèques échouent est très précieux.

@reconbot dans le dernier axios (^0.18.0) vous ne pouvez pas vous connecter à un site https via un serveur proxy. cela entraîne des erreurs EPROTO . il s'agit d'un bug ouvert à ce sujet, mais le problème remonte à des années : https://github.com/axios/axios/issues/1981

edit : en particulier, vous ne pouvez pas utiliser axios pour effectuer des requêtes https via un proxy http. peut-être qu'un proxy https dédié fonctionne, je n'ai pas essayé.

J'espère bien que les correctifs ne sont pas considérés comme de nouvelles fonctionnalités, telles que ma demande d'extraction pour la taille de réponse maximale, que je considère comme une fonctionnalité standard requise de toute bibliothèque mature.

J'ai également examiné d'autres bibliothèques de requêtes avant de choisir celle-ci et la plupart d'entre elles sont très problématiques, incomplètes et boguées. Leurs docs ne mesurent pas non plus. Je ne vois pas vraiment ce qu'une autre bibliothèque peut apporter mais du code non testé et des bugs, ce n'est pas comme s'il y avait une nouvelle approche pour faire des requêtes HTTP. Il s'agit d'envelopper le module http/https et de fournir des valeurs par défaut saines telles que la réponse de mise en mémoire tampon, les réponses de décodage et, bien sûr, la possibilité de promettre le tout . Le plus gros problème de cette bibliothèque ici est l'objectif d'une compatibilité totale, essayer d'être compatible avec les éléments hérités n'apporte que de la douleur et des pratiques de codage héritées. Mais cela peut être corrigé de plusieurs manières. Il existe une bonne base qui peut être remaniée en quelque chose d'élégant, de moderne et de minimaliste. Et surtout fiable. Il existe de nombreuses façons de le faire - divisez-vous en plusieurs fichiers, utilisez ECMA6 avec Babel ou Typescript.

Aucun développeur sensé ne veut 10 bibliothèques qui font la même chose mais manquent de fonctionnalités différentes, sont boguées, non documentées. Cette bibliothèque fonctionne vraiment et j'en suis reconnaissant et j'espère qu'elle ne sera pas obsolète mais ravivée.

Les correctifs ne sont pas considérés comme de nouvelles fonctionnalités. Les correctifs seront fusionnés pendant au moins un an, peut-être même plus longtemps.

-Mikeal

De : mivanovaxway [email protected]
Envoyé : jeudi 11 avril 2019 02:38
À : demande/demande
Cc : Mikeal Rogers ; Mention
Objet : Re : [request/request] Requête passé, présent et futur (#3142)

J'espère bien que les correctifs ne sont pas considérés comme de nouvelles fonctionnalités, telles que ma demande d'extraction pour la taille de réponse maximale, que je considère comme une fonctionnalité standard requise de toute bibliothèque mature.

J'ai également examiné d'autres bibliothèques de requêtes avant de choisir celle-ci et la plupart d'entre elles sont très problématiques, incomplètes et boguées. Leurs docs ne mesurent pas non plus. Je ne vois pas vraiment ce qu'une autre bibliothèque peut apporter mais du code non testé et des bugs, ce n'est pas comme s'il y avait une nouvelle approche pour faire des requêtes HTTP. Il s'agit d'envelopper le module http/https et de fournir des valeurs par défaut saines telles que la réponse de mise en mémoire tampon, les réponses de décodage et, bien sûr, la possibilité de promettre le tout. Le plus gros problème de cette bibliothèque ici est l'objectif d'une compatibilité totale, essayer d'être compatible avec les éléments hérités n'apporte que de la douleur et des pratiques de codage héritées. Mais cela peut être corrigé de plusieurs manières. Il existe une bonne base qui peut être remaniée en quelque chose d'élégant, de moderne et de minimaliste. Et surtout fiable. Il existe de nombreuses façons de le faire - divisez-vous en plusieurs fichiers, utilisez ECMA6 avec Babel ou Typescript.

Aucun développeur sensé ne veut 10 bibliothèques qui font la même chose mais manquent de fonctionnalités différentes, sont boguées, non documentées. Cette bibliothèque fonctionne vraiment et j'en suis reconnaissant et j'espère qu'elle ne sera pas obsolète mais ravivée.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub https://github.com/request/request/issues/3142#issuecomment-482043697 , ou coupez le fil de discussion https://github.com/notifications/unsubscribe-auth/AAACQ8I4BSRtOjqHk637gRfBhkvGfZ .

Les packages TIL 41k sont devenus vulnérables.

Écoutez, je suis d'accord pour dire que la demande devrait disparaître, mais j'ai toujours peur que des packages grand public comme celui-ci modifient leur pipeline de publication. Un mauvais acteur ou une boîte de développement compromise publiant du code malveillant se propagerait efficacement à tous les projets.

Veuillez envisager de resserrer les exigences de poussée npm. Mettre en place une branche pour ci, exiger plusieurs approbations, quelque chose de plus que de simplement pousser à maîtriser.

pas de promesses cependant.

Jeu de mots volontaire? ??

peut-être que le même raisonnement logique devrait être appliqué aux expressjs ? pour la demande, nous avons maintenant le nouveau module shiny got, il n'y a pas de réécriture ou de véritable alternative à expressjs à l'horizon.

express est génial, mais il n'est pas vraiment mis à jour activement avec de nouvelles fonctionnalités ces années

express n'est peut-être pas mis à jour avec de nouvelles fonctionnalités, mais il est activement maintenu et, la dernière fois que j'ai vérifié, quelques personnes sont toujours très intéressées par ce travail. Je ne sais pas s'ils doivent prendre les mesures que nous avons prises pour la dépréciation.

@laoshaw qu'est-ce request ?

Préparation de la dépréciation complète. https://github.com/request/request/pull/3267

Nous sommes totalement obsolètes !

Toutes les versions sur npm notent la dépréciation et le fichier README indique clairement que request a été déprécié.

Cela a été une bonne dizaine d'années, merci à tous ceux qui ont contribué au cours de la dernière décennie. Attendons tous avec impatience de nouvelles bibliothèques mieux adaptées aux changements qui se produisent dans le langage et l'écosystème JS.

Soyons donc SPÉCIFIQUE.
Quel est le remplacement du code lean pour le module de demande ?

À ne pas laisser pendre sur la croûte morte... tant de meilleures options... comme lesquelles ?
Pas GRAND faire tout sous le soleil bibliothèques/modules, s'il vous plaît.

@riclf, nous utilisons https://github.com/googleapis/teeny-request/ pour nous aider à nous node-fetch sous le capot. Il existe également d'autres excellentes options !

Pour une solution prometteuse, il existe également gofer qui est fortement axé sur la communication API. Prise en charge des délais de connexion TCP intégrés, configuration facile (et erreurs riches) pour parler à plusieurs API, etc.

Quelqu'un a-t-il des recommandations pour des clients alternatifs qui prennent bien en charge l'interrogation longue HTTP et se présentent sous la forme d'un émetteur de flux ou d'événements ?

La dernière fois que j'ai vérifié en avril 2019, des alternatives telles que got , node-fetch et axios avaient un problème majeur : lorsqu'une erreur (réseau de bas niveau) s'est produite, ils ont rejeté le trace de pile utile signalée par le noyau Node.js et a généré une nouvelle erreur de haut niveau avec une trace de pile pointant vers la bibliothèque cliente http uniquement. Cela a rendu le débogage des problèmes de niveau de transport pratiquement impossible, par exemple lorsque des proxys sont impliqués.

Existe-t-il une bonne alternative request qui préserve les détails des erreurs fournis par le noyau Node.js ?

@bajtos Je suis presque sûr que gofer ne décore que les erreurs d'origine mais devrait préserver les traces et les messages de la pile.

bent a de belles erreurs et est conçu pour async/wait. C'est aussi incroyablement petit et la taille du paquet est minuscule ;)

L'API n'a rien à voir avec la requête, donc je n'appellerais pas cela un « remplacement ».

@mikeal Pourquoi ça s'appelle bent ? (la demande était un nom plus facile à retenir.)

bent a de belles erreurs et est conçu pour async/wait. C'est aussi incroyablement petit et la taille du paquet est minuscule ;)

L'API n'a rien à voir avec la requête, donc je n'appellerais pas cela un « remplacement ».

Cela ressemble beaucoup à une logique techniquement correcte plutôt qu'à une logique conviviale. Du point de vue de l'utilisateur, bent résout le même problème que la demande mais en mieux. Maintenant, il est coincé avec un pire nom sans raison. Vous pouvez l'appeler demande 3 sans trop de problème imo. Oui, l'API est en panne, mais à quoi sert le serveur.

Vous pouvez l'appeler demande 3 sans trop de problème imo. Oui, l'API est en panne, mais à quoi sert le serveur.

Passez du temps avec bent et vous vous sentirez peut-être différemment.

Ce n'est pas une petite différence dans le nom ou les promesses par rapport aux rappels. L'ergonomie est très différente, les états sur lesquels il fait surface sont très différents, la façon dont il envisage les conditions d'erreur est une approche radicalement différente.

request est une API plus procédurale, vous lui dites de faire quelque chose et elle vous dit ce qui s'est passé, elle ne donne une erreur que si quelque chose échoue irrémédiablement. bent prend les critères de réussite pour l'ensemble du cycle de vie et vous renvoie une API qui échouera si tout sauf les critères de réussite est rempli .

Vous utilisez ces bibliothèques de manière très différente. Il existe d'autres bibliothèques qui sont plus proches de l'API de request si c'est ce que vous voulez, mais après presque 20 ans de travail sur des clients HTTP, j'ai trouvé une approche différente et finalement meilleure que j'encouragerais les gens à considérer, mais je ne vais pas le faire avaler à tout le monde en le faisant request 3.0.

Pourquoi s'appelle-t-il plié ? (la demande était un nom plus facile à retenir.)

Parce que vous le « pliez » dans une forme spécifique (critères de succès très particuliers) et il fournit une API idéale pour le succès de cette forme et échoue sur tout sauf elle.

Le nom est un peu abstrait, mais request est le genre de nom que vous ne pourriez jamais obtenir aujourd'hui. J'ai à peine eu request dans le registre npm et j'ai écrit le registre npm d'origine 😜

qu'en est-il de "got" en remplacement, c'est triste que nous n'ayons pas de remplacement clair alors que la demande est officiellement obsolète.

qu'en est-il de "got" en remplacement, c'est triste que nous n'ayons pas de remplacement clair alors que la demande est officiellement obsolète.

Peut-être devrions-nous considérer le fait que personne n'a écrit un remplacement compatible API comme une indication que l'adoption d'un remplacement compatible API n'est pas souhaitable une fois que vous vous asseyez et travaillez dessus 🧐

C'était certainement mon expérience.

Peut-être que ce que les gens veulent vraiment quand ils demandent un "remplacement", n'est pas tant une alternative compatible avec l'API, mais le point de vue du responsable sur les autres packages déjà disponibles pour résoudre à peu près le même problème et qui rendent ce package non pertinent afin que vous pouvez l'appeler en toute confiance "obsolète".

Et je dirais que la publicité de bent dans l'avis de dépréciation (éventuellement avec d'autres, si cela vous met plus à l'aise) est un excellent moyen de commencer à le faire connaître malgré le nom obscur.

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

Comprenez-vous vraiment ce que « déprécié » signifie vraiment ?

Obsolète. Dans le monde du développement de logiciels, « déprécié » fait référence à des fonctions ou des éléments qui sont en train d'être remplacés par des plus récents. Le terme vient du mot "déprécier", qui signifie désapprouver quelque chose.

En pratique, cela signifie que lorsque je maintiens l'un de mes modules (non open source), je reçois des messages d'erreur stupides.

Qu'en est-il des 151 problèmes et des 55 demandes de tirage ? Les jeter ?

Et je dirais que la publicité pliée dans l'avis de dépréciation (éventuellement avec d'autres si cela vous met plus à l'aise) est un excellent moyen de commencer à la faire connaître, malgré le nom obscur.

C'est BEAUCOUP trop tôt - voir le numéro 2 de bend.

Je pense que cette demande devrait passer en mode limbo - non obsolète, ce qui provoque des avertissements stupides - mais là où RIEN ne sera entrepris, tous les problèmes et tirages seront ignorés et la page README doit être mise à jour pour le noter et, le cas échéant, les références seront inclus à d'autres packages fonctionnellement équivalents.

Qu'en est-il des 151 problèmes et des 55 demandes de tirage ? Les jeter ?

Personne ne les a réparés ou révisés depuis un certain temps, ils ont déjà été « vidés ».

Vos commentaires donnent l'impression qu'il y a une sorte de travail dévoué dans ce projet auquel les gens ont droit. Cela n'a jamais été le cas, request n'est pas un produit publié et soutenu par une entreprise, il a toujours été maintenu par des développeurs open source qui s'en soucient et comme l'écosystème a évolué dans une nouvelle direction, nous avons tous évolué avec lui . Je vous recommande également de passer à autre chose.

Personne ne les a réparés ou révisés depuis un certain temps, ils ont déjà été « vidés ».

Ce que vous voulez dire, c'est que VOUS ne les avez pas revus depuis un certain temps. Soyez juste, nous qui ne sommes pas des collaborateurs n'avons aucun contrôle là-dessus.

Vos commentaires donnent l'impression qu'il y a une sorte de travail dévoué dans ce projet auquel les gens ont droit.

Je ne voulais pas dire ça comme ça, mais dans un sens, c'est vrai, le logiciel Open Source accorde certains droits à l'utilisateur ainsi qu'à la protection des droits du développeur. Ces droits sont d'usage et non de maintien. Lorsque la maintenance ou le développement ultérieur implique des changements de rupture, il faut faire preuve de beaucoup de prudence et de réflexion. C'est un changement radical et à mon avis inutile. Laissez simplement le module tel qu'il est et nous passerons tous au prochain projet - en particulier si l'alternative offre des avantages. En effet, nous serions stupides de ne pas le faire. Mais pour autant que je sache, il n'y a pas pour le moment de réelle alternative.

Le Logiciel Open Source accorde certains droits à l'Utilisateur

Les licences OSS fournissent des droits de redistribution et de modification, aucune garantie d'aucune sorte n'est faite quant à l'adéquation du logiciel à un usage particulier. Aucune garantie n'est jamais faite sur les changements futurs, y compris les changements de rupture potentiels.

Voici le texte pertinent de la licence Apache 2. Presque toutes les licences open source ont cela.

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

C'est un changement radical et à mon avis inutile. Laissez simplement le module tel qu'il est et nous passerons tous au prochain projet - en particulier si l'alternative offre des avantages. En effet, nous serions stupides de ne pas le faire. Mais pour autant que je sache, il n'y a pas pour le moment de réelle alternative.

Voici la chose. Ce code a des bugs connus qui ne seront pas corrigés. Ce code n'est plus maintenu et est obsolète.

L'avertissement de dépréciation est un avis que vous comptez sur du code problématique. Si vous vous contentez d'un code obsolète et problématique, supprimez simplement les messages. Votre problème semble être les avertissements et non l'état du logiciel. Si l'état du logiciel vous convient, supprimez simplement les avertissements.

Nous ne modifierons pas l'état d'obsolescence et les avertissements pertinents pour qu'ils ne correspondent pas à la réalité afin de satisfaire les préoccupations d'un utilisateur particulier concernant les avertissements qu'il peut facilement supprimer s'il ne se soucie pas de s'appuyer sur des modules obsolètes.

besoin d'aide !!!..j'ai ce problème lorsque j'essaie d'installer node-gyp 3.6.2
PS C:\Users\User> npm install --global [email protected]
npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142
npm ERR ! chemin C:\Users\User\AppData\Roamingnpm\node-gyp.cmd
npm ERR ! code EEXIST
npm ERR ! Refuser de supprimer C:\Users\User\AppData\Roamingnpm\node-gyp.cmd : est en dehors de C:\Users\User\AppData\Roamingnpm\node_modules\node-gyp et non d'un lien
npm ERR ! Le fichier existe : C:\Users\User\AppData\Roamingnpm\node-gyp.cmd
npm ERR ! Éloignez-le et réessayez.

npm ERR ! Un journal complet de cette course peut être trouvé dans:
npm ERR ! C:\Users\User\AppData\Roamingnpm-cache_logs\2020-02-13T05_12_13_683Z-debug.log

@mikeal Oh, c'est un cas intéressant. Avoir le numéro de problème dans l'avis de dépréciation pourrait apporter beaucoup de commentaires sans rapport ici, comme @Meharab l'a démontré.

Peut-être est-il temps d'empêcher d'autres commentaires ici ?

UPDATE : 5 jours plus tard et les commentaires s'accumulent vraiment.

@mikeal Merci pour ces années

Bonsoir demande. On se retrouve de l'autre côté.

la requête va fonctionner pour toujours (telle qu'elle est), car c'est du JavaScript .. bien à moins que Node n'introduise un changement radical en dépréciant une API de base qu'il utilise

la requête va fonctionner pour toujours (telle qu'elle est), car c'est du JavaScript .. bien à moins que Node n'introduise un changement radical en dépréciant une API de base qu'il utilise

Nan.
Ce code a des bugs connus qui ne seront pas corrigés. Ce code n'est plus maintenu et est obsolète. (cit.)

Donc, la demande va avoir des bugs non corrigés pour toujours ne va pas fonctionner pour toujours ...

Je ne comprends pas. Alors, que suis-je censé faire officiellement maintenant, pour ne pas recevoir l'avertissement de dépréciation ?

Supprimer request . Cela peut impliquer de le supprimer de vos propres dépendances, de mettre à niveau des packages qui le suppriment dans des versions plus récentes ou de supprimer des packages qui n'ont pas encore été mis à jour avec des versions plus récentes.

Bonjour.

J'essaye d'installer cordova.

npm install -g cordova

je continue à recevoir cette erreur.
Microsoft Windows [Version 10.0.18362.592]
(c) 2019 Microsoft Corporation. Tous les droits sont réservés.

C:\Users>npm install -g cordova
npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142
C:\Users\AppData\Roamingnpm\cordova -> C:\Users\AppData\Roamingnpm\node_modules\cordova\bin\cordova

• [email protected]
  mis à jour 1 paquet en 10.279s

Existe-t-il un autre moyen d'installer Cordova ?
Un moyen de contourner cet achat?

Oui. D'accord. Je vais supprimer la demande. Mais quoi alors ?

Donc, sur node.js, je dois passer à .. idk.. axios ?

Que suis-je censé mettre à la place de la demande ?

Je comprends que l'idée est de réécrire toutes les fonctions où la demande était présente ?

Existe-t-il un package que je pourrais simplement modifier avec find&replace avec regex ?

Existe-t-il un remplacement officiel pour la demande ou sommes-nous simplement libres maintenant de trouver tout ce qui apparaît en premier sur Google ? je ne comprends pas

Existe-t-il un remplaçant officiel pour la demande

Non, vous pouvez utiliser ce que vous voulez, bien que le même développeur travaille sur bent

Il y a aussi le fork postman-request qui a reçu un certain nombre de correctifs, ~mais il n'a eu aucune activité depuis la dépréciation de request .~

Parce qu'ils n'ont pas de page de problèmes, je suppose que je vais essayer de demander ici :

@coditva @codenirvana @shamasis @vikiCoder @czardoz

Toutes nos excuses pour les mentions, mais quels sont les plans pour postman-request maintenant que request est officiellement mort ? postman-request continuera-t-il à être maintenu ou sera-t-il également obsolète ?

Besoin d'aide!!! J'essaye d'installer angulaire, j'ai un problème
npm install -g @angular/cli
npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142
npm ERR ! code EEXIST
npm ERR ! chemin C:\Users\FARHAN\AppData\Roamingnpm\node_modules\@angular\cli\bin\ng
npm ERR ! dest C:\Users\FARHAN\AppData\Roamingnpm\ng.cmd
npm ERR ! EEXIST : le fichier existe déjà, shim cmd 'C:\Users\FARHAN\AppData\Roamingnpm\node_modules\@angular\cli\bin\ng' -> 'C:\Users\FARHAN\AppData\Roamingnpm\ng.cmd'
npm ERR ! Le fichier existe : C:\Users\FARHAN\AppData\Roamingnpm\ng.cmd
npm ERR ! Supprimez le fichier existant et réessayez, ou exécutez npm
npm ERR ! avec --force pour écraser les fichiers imprudemment.

npm ERR ! Un journal complet de cette course peut être trouvé dans:
npm ERR ! C:\Users\FARHAN\AppData\Roamingnpm-cache_logs\2020-02-15T09_52_19_067Z-debug.log

Quelles sont les alternatives à request ? Angular en dépend toujours. J'espère qu'ils mettront à jour leur base de code bientôt.

J'ai une solution à court terme sur laquelle Mikeal Rogers reculera, peut-être même s'en prendra à moi. Cette dépréciation actuelle s'est déroulée en 2 phases imprévues - 1) une discussion générale sur sa nécessité, 2) BANG, avec un préavis d'environ 30 minutes et elle a été mise en œuvre. Tout l'enfer s'est déchaîné.

Je demande à @mikeal s'il

Les 3 phases-
1) Discussion : du 20 mars 2019 au 15 février 2020
2) Avis de dépréciation de 6 mois : 15 février 2020
3) Mise en œuvre de la dépréciation : 15 août 2020

De cette façon, non seulement les frameworks et les projets d'application ne sont PAS instantanément cassés, ce qui est tout simplement trop dur, mais cette communauté peut désormais utiliser CETTE zone de discussion pour partager des alternatives, les +/- au cours des prochains mois et mettre les alternatives en place avant la date limite de 6 mois. Ensuite, quand cela arrive, nous pouvons tous le saluer, crier cheerio, et rien n'est cassé.

S'il vous plaît, comprenez, je ne fais aucun argument sur la nécessité de sa dépréciation, ou le droit du créateur de le faire... Je suggère un calendrier de préavis en 3 étapes, comme indiqué ci-dessus, qui expliquera son très utilisation importante dans la communauté des développeurs et les applications vivantes dans le monde aujourd'hui en fonction du module de demande.

Mikeal, s'il vous plaît, tenez compte de ma suggestion, supprimez le statut de dépréciation aujourd'hui et annoncez le préavis de 6 mois. Moins de 6 mois n'est pas suffisant pour beaucoup d'entre nous, 6 est juste. J'apprécierais cela, nous le ferions tous.

Merci beaucoup de m'avoir écouté,
-Ric Fink

L'ajout d'un avertissement de dépréciation ne casse rien cependant, il avertit simplement les utilisateurs qu'il pourrait être cassé à l'avenir. Je préfère voir un message de dépréciation plus tôt que d'attendre la discussion de la communauté avant de savoir que je devrai éventuellement remplacer un package.

Aussi, rappel amical que ce paquet a été développé via open source gratuitement, et que le mainteneur ne vous doit rien. Si vous souhaitez continuer à utiliser le package, vous pouvez le forker et continuer à le maintenir vous-même.

@riclf

Besoin d'aide!!! J'essaye d'installer angulaire, j'ai un problème
npm install -g @angular/cli
npm WARN obsolète [email protected] : la demande a été obsolète, voir #3142
npm ERR ! code EEXIST
npm ERR ! chemin C:\Users\FARHAN\AppData\Roamingnpm\node_modules@angular\cli\bin\ng
npm ERR ! dest C:\Users\FARHAN\AppData\Roamingnpm\ng.cmd
npm ERR ! EEXIST : le fichier existe déjà, shim cmd 'C:\Users\FARHAN\AppData\Roamingnpm\node_modules@angular\cli\bin\ng' -> 'C:\Users\FARHAN\AppData\Roamingnpm\ng.cmd'
npm ERR ! Le fichier existe : C:\Users\FARHAN\AppData\Roamingnpm\ng.cmd
npm ERR ! Supprimez le fichier existant et réessayez, ou exécutez npm
npm ERR ! avec --force pour écraser les fichiers imprudemment.

npm ERR ! Un journal complet de cette course peut être trouvé dans:
npm ERR ! C:\Users\FARHAN\AppData\Roamingnpm-cache_logs\2020-02-15T09_52_19_067Z-debug.log

Cela semble avoir été résolu par la dernière version d'Angular dans laquelle request est remplacé par node-fetch .

@AURZeeshan
Votre erreur n'est pas liée à cela. Vous voyez juste un avertissement de ce package, l'erreur est différente.

@riclf

Besoin d'aide!!! J'essaye d'installer angulaire, j'ai un problème
npm install -g @angular/cli
npm WARN obsolète [email protected] : la demande a été obsolète, voir #3142
npm ERR ! code EEXIST
npm ERR ! chemin C:\Users\FARHAN\AppData\Roamingnpm\node_modules@angular\cli\bin\ng
npm ERR ! dest C:\Users\FARHAN\AppData\Roamingnpm\ng.cmd
npm ERR ! EEXIST : le fichier existe déjà, shim cmd 'C:\Users\FARHAN\AppData\Roamingnpm\node_modules@angular\cli\bin\ng' -> 'C:\Users\FARHAN\AppData\Roamingnpm\ng.cmd'
npm ERR ! Le fichier existe : C:\Users\FARHAN\AppData\Roamingnpm\ng.cmd
npm ERR ! Supprimez le fichier existant et réessayez, ou exécutez npm
npm ERR ! avec --force pour écraser les fichiers imprudemment.
npm ERR ! Un journal complet de cette course peut être trouvé dans:
npm ERR ! C:\Users\FARHAN\AppData\Roamingnpm-cache_logs\2020-02-15T09_52_19_067Z-debug.log

Cela semble avoir été résolu par la dernière version d'Angular dans laquelle request est remplacé par node-fetch .

J'ai installé la dernière version CLI. Il lance toujours le même avertissement

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

@vighnesh153 Quelle version de @angular/cli est spécifiée dans votre package.json ? Il semble que certaines dépendances nécessitent une demande, mais pas le package de base lui-même. Voir http://npm.anvaka.com/#/view/2d/%2540angular%252Fcli

Vous avez peut-être raison. Je ne sais pas exactement lequel des packages utilise le package request. Voici un aperçu des 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 installer
npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142

quand je veux terminer "npm install" dans \vue-devtools-dev, j'ai averti à ce sujet
Comment puis-je le résoudre ?

Je respecte totalement votre décision de le désapprouver et vous souhaite le meilleur pour l'avenir.

En ce qui concerne les personnes venant sur le fil à la recherche de "Alors que dois-je utiliser à partir de maintenant ??", got ou axios sont ce que vous recherchez.

Pathétique. Il est temps de migrer vers node-fetch.

...sauf si vous vous demandez si node-fetch est un bon remplacement pour request , ou même activement maintenu. Pathétique en effet.

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

D'ailleurs, les personnes qui optent pour node-fetch doivent vraiment faire attention. Cette bibliothèque, bien que géniale, a elle-même de graves problèmes de maintenance.

Pathétique. Il est temps de migrer vers node-fetch.

...sauf si vous vous demandez si node-fetch est un bon remplacement pour request , ou même activement maintenu. Pathétique en effet.

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

Au moins, node-fetch n'est pas obsolète. L'abandon définitif de la demande a causé des problèmes avec les systèmes d'autobuild. Je ne comprends pas et n'accepte pas ce mouvement et, à mon avis, une simple note expliquant que la bibliothèque n'est pas maintenue serait suffisante au lieu d'une dépréciation dure. C'est pourquoi je considère cette situation pathétique.

à mon avis, une simple note expliquant que la lib n'est pas maintenue suffirait

C'est exactement ce qu'est un avis de dépréciation : une simple note.

@asgetz tout ce que fait npm est d'imprimer cet avertissement lors de l'installation d'un package obsolète, tout le reste fonctionne exactement comme avant.

J'ai des problèmes avec les fichiers less.js fonctionnant sur github. Ils fonctionnent très bien dans PHP. Lorsque j'ai essayé d'en mettre moins dans la commande, cet avertissement est apparu. Des idées sur quel est le problème?

La demande de

Existe-t-il un remplacement pour request , mais avec l'interface de flux de node.js ? J'ai trouvé que node-fetch , axios sont tous deux basés sur Promise .

J'aimerais connaître un remplacement pour l'interface de flux, qui est plus pratique pour les cas d'utilisation de niveau inférieur.

@ maple3142 got a une interface de flux (ainsi que des promesses) et un guide de migration .

@asgetz

npm m'indique que je dois l'installer moi-même maintenant.

C'est de quelle façon cela indique-t-il cela. Lorsque j'installe request je reçois juste l'avis de dépréciation et tout fonctionne comme avant.

mon utilisation prévue pour elle est si petite

Dans ce cas, jetez peut-être un coup d'œil au plié qui est beaucoup plus léger et semble bien fonctionner.

@mikeal pouvez-vous jeter un œil à https://github.com/request/request/pull/3245 proxyHeaderExclusiveList est l'une des meilleures fonctionnalités de ce package et il ne fonctionne pas correctement.
Réparons ça !

@kauegimenes ce paquet est obsolète ... rien ne sera plus jamais réparé

@kevinvanrijn Je ne suis plus activement impliqué dans la maintenance de postman-request , mais le projet est définitivement vivant et la dernière version date d'il y a un mois. Je laisserai cependant les mainteneurs actifs intervenir sur les plans à plus long terme.

@czardoz C'est bon à savoir. J'ai un tas de petits projets (tous privés) dépendant de request que je ne peux pas passer du temps à réécrire. Déposer postman-request en remplacement signifie que je peux compter sur eux pour continuer à fonctionner un peu plus longtemps.

cloudscraper souffre également d'une maintenance lente et ne pourra probablement pas encore s'éloigner de request . Le fait d'avoir postman-request disponible en option signifie qu'il ne risquera au moins pas de devenir lui-même obsolète.

@ Edo78 pourquoi tu dis ça ? j'ai toujours la foi qu'un jour mes relations publiques seront fusionnées

Les commiters qui sont encore actifs essaieront de fusionner les correctifs en temps opportun, sans promesse cependant.

Au fait, les personnes qui optent pour la récupération de nœuds doivent vraiment faire attention. Cette bibliothèque, bien que géniale, a elle-même de graves problèmes de maintenance.

@csvan Pouvez-vous expliquer un peu? Je ne vois que quelques problèmes

Je connais très peu le npm. Je l'ai utilisé pour installer une API et j'ai reçu des avertissements que je ne comprends pas. Ils me dirigent ici. C'est totalement inutile pour moi. Quelqu'un devrait poster ici quelque chose d'utile pour ceux d'entre nous dirigés ici ou le message dans npm devrait être corrigé pour être plus utile. Voici les messages que j'ai reçus.

npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142
npm WARN saveError ENOENT : aucun fichier ou répertoire de ce type, ouvrez 'C:\Users\Sam\package.json'
npm notice a créé un fichier de verrouillage sous le nom package-lock.json. Vous devez valider ce fichier.
npm WARN enoent ENOENT : aucun fichier ou répertoire de ce type, ouvrez 'C:\Users\Sam\package.json'
npm WARN Sam Aucune description
npm WARN Sam Aucun champ de référentiel.
npm WARN Sam Pas de données README
npm WARN Sam Aucun champ de licence.

De plus, il n'y a pas de fichier package.json mais il existe un package-lock.json. Je ne sais pas quoi chercher là-bas.

@SimpleSamples le package est obsolète et ne sera pas activement maintenu en dehors d'éventuelles corrections de bogues, comme l'explique clairement le texte. NPM vous avertit simplement que vous utilisez un package obsolète, afin que vous ayez la possibilité de passer à autre chose.

Si vous ne comprenez pas ce que signifie la dépréciation, il existe plusieurs articles utiles à rechercher sur Google.

Oui, je comprends ce que signifie la dépréciation et donc le lien vers le
la discussion sur le passé, le présent et l'avenir de Request ne fournit aucune
clarification, cela ne fait qu'ajouter à la confusion. Ou y a-t-il quelque chose de plus que je fais
ne comprends pas et vous ne clarifiez pas? Si c'est seulement dire que
La demande est obsolète, c'est tout ce qu'il faut dire, au lieu de
ce qui implique qu'il y a quelque chose de plus que nous devons faire.

Il serait plus utile de dire (lien vers un article
expliquant) ce qui le remplace, ou toute action dont nous devrions être conscients.

Christopher Svanefalk [email protected]
mardi 18 février 2020 22:45

@SimpleSamples https://github.com/SimpleSamples le paquet est
obsolète et ne recevra plus de mises à jour, car le texte
explique clairement. NPM vous avertit simplement que vous utilisez un
paquet obsolète.

Si vous ne comprenez pas ce que signifie la dépréciation, il existe plusieurs
articles utiles à une recherche Google.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/request/request/issues/3142?email_source=notifications&email_token=ACK22R4G7LHULMPO6DHH273RDTIP7A5CNFSM4HCP6LRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJZEMKTDN5WW62237 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/ACK22R7UFQSYKW7NEYZ4OTDRDTIP7ANCNFSM4HCP6LRA .

S'il dit seulement que la demande est obsolète, c'est tout ce qu'il faut dire

Ouais, foutre quelqu'un qui apprécie le contexte et aime connaître les raisons des décisions ou qui veut connaître les détails de la suppression progressive. :P
Pour être sérieux, s'il y avait un "pourquoi" ajouté à l'avertissement, cela aurait-il évité votre confusion ?

"npm WARN deprecated [email protected] : la demande a été dépréciée, voir #3142 pour savoir pourquoi "

Vous avez raison. Je n'ai pas vu la partie "pourquoi".

Espen a écrit :

"pourquoi"

@SimpleSamples désolé si je me trompe, mais je ne vois vraiment pas la confusion. Request est obsolète, et le texte de ce numéro explique assez clairement pourquoi et ce que cela implique.

D'où vous vient l'idée que vous devez faire quelque chose ? Une dépréciation n'est qu'une dépréciation, la façon dont vous la gérez dépend de vous.

Il n'y a rien de mal avec les modèles utilisés par les requêtes. Au contraire, il existe une énorme communauté dans l'écosystème javascript qui utilise toujours ces modèles. D'après mon expérience, il s'agit d'une communauté bien plus importante que la minorité vocale (la plupart des grandes entreprises) qui ont les ressources nécessaires pour constamment détruire des bases de code parfaitement fonctionnelles pour rien de plus que la vanité et l'arrogance des développeurs.

Je suis désolé que vous soyez tombé dans ce piège, la demande a été d'un grand service à la communauté et j'espère sincèrement que vous reconsidérez votre décision.

Oui, je suis triste que ce soit parti. Les rappels ne sont pas mauvais, pas plus que les promesses ou l'attente asynchrone.

Je pense que ce qui vous manque @SimpleSamples, c'est que le reste des avertissements que vous avez collés n'a rien à voir avec l'avertissement de dépréciation qui vous a amené ici. Vous n'avez rien à faire à propos de la dépréciation, mais vous voudrez peut-être faire quelque chose à propos de votre package.json manquant (ou de tout ce qui cause ces autres avertissements).

Alors, que sommes-nous censés faire maintenant avec tous ces packages qui utilisent request sous le capot ?

J'ai essayé de remplacer request par @root/request dans l'un de ces packages, en supposant qu'il s'agissait bien d'un remplacement instantané, mais je n'ai pas pu le faire fonctionner .

J'ai aussi essayé de remplacer request par quelque chose comme...

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

... et...

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

... mais je n'arrivais pas à le faire fonctionner non plus.

Et maintenant? En l'absence d'un remplacement instantané qui tient réellement ses promesses, sommes-nous censés tous vivre avec plusieurs dépendances dans notre node_modules qui reposent sur un package obsolète, dont plusieurs ne semblent pas être maintenu? Et pourquoi?

Je comprends que request est devenu obsolète à plusieurs égards, mais en dépréciant ce package sans offrir un remplacement approprié, les modules 41K dépendent désormais directement d'un package déprécié. Si nous considérons les packages qui utilisent au moins un de ces modules de 41K comme une dépendance, nous pouvons parler de centaines de milliers, voire de millions de packages qui sont affectés.

Bien sûr, je suppose que pour certains packages, il est facile de remplacer request par quelque chose comme fetch , axios , superagent ou le natif de Node.js http.request & https.request . Mais par ex. dans le cas où les requêtes sont redirigées vers une autre requête (comme avec html2canvas-proxy ), j'ai du mal à comprendre ce qui se passe là-bas... et je ne peux pas vraiment me permettre de passer de nombreuses heures à essayer de remplacer juste quelques lignes de code obsolète alors que je devrais en fait faire des choses plus importantes.

J'ai toujours été fatigué de trop compter sur une multitude de packages interdépendants qui sont chargés en arrière-plan avec un gestionnaire de packages. Oui, je suppose que cela peut décharger une grande partie du gros du travail sur des tiers, mais au lieu de cela, vous avez tout un tas d'autres maux de tête à gérer.

Les gestionnaires de paquets nous donnent un faux sentiment de sécurité. Toute la débâcle du Leftpad il y a 4 ans semble n'avoir pas réussi à ouvrir les yeux des gens sur les risques encourus. Je suis sûr que cela ne fera pas de différence non plus. Néanmoins, j'ai l'impression de devoir souligner qu'il y a quelque chose qui ne va vraiment pas lorsqu'un package obsolète ou cassé peut avoir un impact sur des millions de packages dans l'ensemble de l'écosystème. Et cela risque de ne faire qu'empirer, car de plus en plus de projets seront abandonnés, obsolètes ou même brisés à mesure que le temps passe, et nous vivrons tous dans l'enfer de la dépendance...

Mais bon... Je suppose qu'au moins cela signifie qu'il y aura toujours une demande pour que les développeurs JS nettoient le gâchis $%#@...

@jslegers

Néanmoins, j'ai l'impression de devoir souligner qu'il y a quelque chose qui ne va vraiment pas lorsqu'un package obsolète ou cassé peut avoir un impact sur des millions de packages dans l'ensemble de l'écosystème.

La seule chose qui ne va pas, c'est la panique dont vous et les autres semblez souffrir. leftpad est parti, supprimé. Cela ne peut pas arriver maintenant. La demande a simplement été dépréciée ; ça ne va nulle part. Si cela fonctionne maintenant, cela continuera à fonctionner de la même manière.

Il n'y a aucun impact sur des millions de colis, sauf si vous comptez un avertissement bénin.

J'ai aussi essayé de remplacer la demande par quelque chose comme...

S'il vous plaît, arrêtez de paniquer ; s'il vous plaît arrêtez d'essayer de résoudre un problème inexistant. Utilisez les packages de votre choix : la dépréciation de la demande ne les endommagera pas. Progressivement, leurs responsables de paquet peuvent passer à un autre paquet. Ou ils peuvent pas. Ce n'est pas grave. Rien n'a changé, à part l'apparition d'un petit message.

il y aura toujours une demande pour que les développeurs JS nettoient le gâchis $%#@...

Il n'y a pas de désordre. Juste progresser.

Il n'y a aucun impact sur des millions de colis, sauf si vous comptez un avertissement bénin .

Dépréciation, par exemple. une partie de votre API ou d'une bibliothèque signifie essentiellement que vous la désignez officiellement comme "obsolète" et que vous encouragez activement les utilisateurs à opter pour autre chose.

La dépréciation est généralement utilisée comme une étape intermédiaire entre la prise en charge officielle de quelque chose et l'abandon officiel de la prise en charge de quelque chose, pour donner aux développeurs le temps de remplacer tout ce que vous avez déprécié jusqu'à ce que cette chose ne soit plus disponible ou rétrocompatible.

Les avertissements de dépréciation sont censés vous rendre nerveux. Ils sont conçus comme un appel à l'action. Fondamentalement, le but de la dépréciation est d'offrir aux développeurs une "période de grâce", leur permettant de mettre à jour leur code avant que quelqu'un ne débranche la prise.

Et ils ne doivent pas être utilisés à d'autres fins. La dépréciation n'est pas censée simplement informer vos utilisateurs que "Notre API ne suit pas les dernières normes de codage" ou "Je n'ai plus le temps de maintenir ce projet"... même si la bibliothèque est assez stable et jolie sûr à utiliser dans + 99% de tous les cas d'utilisation et susceptible de continuer à fonctionner correctement pendant au moins la prochaine décennie. Ce n'est pas ce que signifie la dépréciation, et utiliser des avertissements de dépréciation juste pour exprimer un message comme celui-ci crée un très mauvais précédent IMO.

En outre, il est tout simplement moche d'avoir vos journaux npm install pleins d'avertissements de dépréciation. Ça a l'air bâclé. C'est une sorte de drapeau rouge et crée une mauvaise première impression pour les personnes qui essaient votre bibliothèque ou votre framework. Surtout si les gens vous paient pour utiliser votre bibliothèque / framework, vous voulez leur donner un processus d'installation agréable / propre sans aucun avertissement.

Rien n'a changé, à part l'apparition d'un petit message.

Ce petit message a l'air bâclé et est censé n'avoir d'autre but que d'appeler à l'action... un appel à remplacer un paquet obsolète par quelque chose d'autre.

Cela n'a peut-être pas d'importance pour vous, mais cela compte vraiment pour moi et pour d'autres personnes.

Il n'y a pas de désordre. Juste progresser.

Je suppose que vous faites partie de ces personnes qui ne savent pas faire la différence entre le changement et le progrès.

Quoi qu'il en soit, j'ai remarqué que d'autres personnes dans les commentaires suggéraient d'utiliser postman-request . Contrairement à @root/request , celui-ci semble fonctionner comme un remplacement instantané, je vais donc mettre à jour tous mes packages avec celui-ci pour le moment...

Je pense que ce qui vous manque @SimpleSamples, c'est que le reste des avertissements que vous avez collés n'a rien à voir avec l'avertissement de dépréciation qui vous a amené ici. Vous n'avez rien à faire à propos de la dépréciation, mais vous voudrez peut-être faire quelque chose à propos de votre package.json manquant (ou de tout ce qui cause ces autres avertissements).

Touché !

Le point a été fait, mais les attaques personnelles continuent. Vous êtes très intelligents et très compétents sur le plan technique, mais il y a place à l'amélioration de l'expertise personnelle.

Le point a été fait, mais les attaques personnelles continuent. Vous êtes très intelligents et très compétents sur le plan technique, mais il y a place à l'amélioration de l'expertise personnelle.

Être intelligent n'empêche malheureusement pas les gens de laisser leurs émotions obscurcir leur jugement... surtout lorsque leurs affaires se produisent comme si des choses se dépréciaient apparemment sans une bonne raison ou un consensus général sur le but de la dépréciation.

Quoi qu'il en soit, je pense que j'ai fait mon point assez clairement. J'aimerais terminer en encourageant @mikeal , @reconbot ou tout autre mainteneur de ce projet à proposer officiellement postman-request comme remplacement complet des fonctionnalités pour request , et éventuellement @root/request pour ceux qui ont juste besoin d'un sous-ensemble limité de request et ne se soucient pas de, par exemple. ruisseaux. Cela permet à tout responsable de paquet de supprimer request et de se débarrasser du message d'obsolescence ennuyeux sans passer plus de quelques minutes de temps de développement sur ce problème, et sans avoir à refactoriser l'intégralité de sa bibliothèque ou de son application.

@mikeal venant de la réalité de la demande obsolète, je voudrais vous demander un moment de réflexion qui sera utile à certains ou peut-être à beaucoup d'entre nous. Vous disposez de 2 modules de requête http ultérieurs, à la suite de la requête : r2 et bend.

Puis-je vous demander de nous donner un bref résumé des différences, des avantages et des avantages ou inconvénients du passage à l'une de ces demandes de remplacement par rapport à l'autre. J'ai confiance en votre travail.

Merci pour ce temps, et puis-je être sûr de dire merci pour les années du module de demande.

-Ric

Est-ce que request-promise-native également obsolète ou est-ce la bonne chose à utiliser ?

@ anton-bot https://github.com/request/request-promise-native#deprecated

[email protected] : la demande a été dupliquée ....impossible de créer un nouveau projet

[email protected] : la demande a été dupliquée ....impossible de créer un nouveau projet

Vous pouvez créer un projet comme toujours. NPM vous donne simplement un avertissement.

Pourquoi ce projet a-t-il été supprimé ?

Oui c'est bon

Utilisé par 4 476 352 référentiels, 52 377 packages.
Dites adieu à la légende.

Pourquoi ce projet a-t-il été supprimé ?

@jleppert ce n'est pas le cas, veuillez lire le problème sur

J'ai essayé d'installer angulaire sous Linux, puis sous Windows et dans les deux, je n'ai pas pu, après avoir exécuté la commande npm install -g @ angular / cli @ latest dans les deux, j'ai rencontré cette erreur

C:\Users\Hanzell>npm install -g @angular/cli@latest
npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142
C:\Users\Hanzell\AppData\Roamingnpm\ng -> C:\Users\Hanzell\AppData\Roamingnpmnode_modules\@angular\cli\bin\ng

@angular/ cli @
nœud ./bin/postinstall/script.js

• @angular/ [email protected]
  ajouté 260 packages de 205 contributeurs en 188.027s

Ensuite, j'ai créé le référentiel et cela est apparu

C:\Users\Hanzell\Desktop>ng nouveau
? Quel nom aimeriez-vous utiliser pour le nouvel espace de travail et le projet initial ? salut
? Souhaitez-vous ajouter un routage angulaire ? Non
? Quel format de feuille de style souhaitez-vous utiliser ? CSS
CRÉER hola/angular.json (3551 octets)
CRÉER hola/package.json (1281 octets)
CRÉER hola/README.md (1021 octets)
CRÉER hola/tsconfig.json (543 octets)
CRÉER hola/tslint.json (1953 octets)
CRÉER hola/.editorconfig (246 octets)
CRÉER hola/.gitignore (631 octets)
CREER hola/browserslist (429 octets)
CRÉER hola/karma.conf.js (1016 octets)

• Installation des packages...npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142g.spec.json (270 octets)
  npm ERR ! Fin inattendue de l'entrée JSON lors de l'analyse près de '...f8x\n2SbOSCsT+zdXwIaf'

npm ERR ! Un journal complet de cette course peut être trouvé dans:
npm ERR ! C:\Users\Hanzell\AppData\Roamingnpm-cache_logs\2020-03-01T05_15_55_441Z-debug.log
× L'installation du package a échoué, voir ci-dessus.
Le workflow schématique a échoué. Voir au dessus.
CRÉER hola/src/assets/.gitkeep (0 octets

aider!

@RiveraHan, les problèmes que vous rencontrez ne sont pas liés à la dépréciation de request .

Cela étant dit, j'étais curieux. Bien que je n'aie pas utilisé angulaire depuis ses jours JS, j'ai essayé. Notez que je ne voulais pas ajouter le cli angulaire à mes modules globaux, j'ai donc procédé un peu différemment. J'ai testé ce qui suit avec npm 6.14.1 , node 12.16.1 et 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 vous installez le cli angulaire globalement, supprimez simplement ../w1/node_modules/.bin/ et w1/node_modules/.bin/ de ng ci-dessus devrait être trouvé globalement.

@millette Cela n'a pas fonctionné sur Linux ubuntu et windows 10. C'est la première fois que j'installe l'angular

@RiveraHan ce n'est pas une erreur. c'est un avertissement npm. Si la configuration que vous utilisez échoue sur les avertissements npm, vous devez alors vérifier la configuration pour cela.

@csvan Mais, je me suis rendu compte en ouvrant le nouveau projet dans mon éditeur de code que le dossier node_modules n'apparaissait pas et fais une petite recherche pour générer à nouveau le dossier node_modules et c'est avec la commande npm install que je le fais et la même chose apparaît une autre erreur .

@RiveraHan oui, mais encore une fois, cela n'a rien à voir avec request ou npm - les avertissements npm n'interrompront pas une installation à moins que votre environnement de développement ne soit configuré pour le faire. Vous devez déterminer pourquoi votre environnement ne tolère pas les avertissements npm et ce que vous pouvez faire à ce sujet - si c'est même le problème dans votre cas. Cela pourrait très bien être quelque chose de complètement différent.

@anton-bot propose donc de reprendre le projet et de mettre tout le travail que les mainteneurs actuels n'ont pas le temps de faire. C'est assez arrogant de dire aux autres comment gérer leur projet si vous n'êtes pas prêt à travailler vous-même pour y arriver. C'est open source.

@mikeal a expliqué assez clairement pourquoi request est obsolète. C'est la chose responsable à faire, c'est une bonne décision, et il est peu probable qu'elle soit renversée.

Aussi, ceci :

De plus, de manière réaliste, les gens ne vont pas remplacer leur code de travail parfaitement fonctionnel qui utilise la requête par autre chose. Voir certaines des demandes d'extraction liées - ce n'est tout simplement pas une idée que les gens veulent faire.

C'est pourquoi nous nous retrouvons avec un code hérité de déchets qui dépend d'anciens modules qui étaient "parfaitement du bon code" à leur époque. Une partie de la maintenance du logiciel consiste à se débarrasser des modules anciens et obsolètes, en les remplaçant par des modules activement maintenus.

@anton-bot Utilisez simplement @root/request qui est essentiellement une implémentation conforme à 80% de request qui utilise des API HTTP Node modernes sous le capot.

@anton-bot Il vous manque clairement plusieurs faits de la vie :

1. Il s'agit d'un logiciel gratuit et open source. Vous n'avez pas le droit de dire aux responsables de "Just stop it".
2. La demande a dépassé sa date de péremption (mais pas sa date de péremption). Il est devenu lourd et démodé.
3. @mikeal a produit au moins deux nouveaux packages qui remplacent la demande. Ils sont tous les deux beaucoup plus légers.
4. Si vous et d'autres personnes souhaitez continuer à l'utiliser, vous êtes libre de le faire. Rien dans la dépréciation ne vous en empêche.

Personnellement, j'en ai profité pour faire évoluer progressivement mes forfaits. kraken-exchange , par exemple, est passé de 5,9 Mo à 284 Ko installés, en passant à bent .

@csvan a dit que vous étiez "assez arrogant". C'est une expression beaucoup plus polie que celle que j'aurais utilisée.

@anton-bot Utilisez simplement @root/request qui est essentiellement une implémentation de requête conforme à 80% qui utilise des API HTTP Node modernes sous le capot.

Une conformité à 80 % n'est pas suffisante.

J'utilise des dépendances qui reposent sur les 20 % manquants (par exemple, les flux). Pour cela, vous avez besoin d'un remplacement complet comme postman-request .

J'ai suggéré dans un commentaire précédent (qui semble avoir été censuré / supprimé) que les mainteneurs remettent leur projet à l'équipe Postman, afin qu'ils puissent remplacer l'implémentation de postman-request request par l'implémentation de postman-request , car ce paquet est toujours activement maintenu, complet et corrige certains des bogues jamais corrigés dans request .

De cette façon, les auteurs originaux de request pourraient prendre du recul et profiter de leur "retraite" bien méritée sans effrayer ou ennuyer beaucoup de gens en dépréciant inutilement request .

Il s'agit d'un logiciel gratuit et open source. Vous n'avez pas le droit de dire aux responsables de "Just stop it".

Bien sûr qu'il le fait. Et de la même manière, les mainteneurs ont le droit de dire "f * you".

La demande a dépassé sa date de péremption (mais pas sa date de péremption). Il est devenu lourd et démodé.

Toujours pas une raison valable de déprécier.

@mikeal a produit au moins deux nouveaux packages qui remplacent la demande. Ils sont tous les deux beaucoup plus légers.

Donc?

Des milliers de packages utilisent encore request aujourd'hui et génèrent désormais inutilement des avertissements de dépréciation pendant npm install . Cela n'aurait pas dû se produire et aurait pu être facilement évité par ex. passer le flambeau à l'équipe Postman ou simplement laisser ce projet mourir sereinement.

Si vous et d'autres personnes souhaitez continuer à l'utiliser, vous êtes libre de le faire. Rien dans la dépréciation ne vous en empêche.

Bien sûr que oui.

Les clients qui deviennent nerveux lorsqu'ils voient des avertissements de dépréciation pendant npm install empêchent beaucoup d'entre nous de rester assis et de ne rien faire.

Dépréciation = un appel à l'action. Cela donne essentiellement aux gens une période de grâce pour remplacer leurs dépendances jusqu'à ce que leurs dépendances se brisent. Il ne doit pas être utilisé dans d'autres cas que dans les cas où les dépendances sont censées casser les fonctionnalités existantes après la fin d'une période de grâce.

Personnellement, j'en ai profité pour faire évoluer progressivement mes forfaits. kraken-exchange, par exemple, est passé de 5,9 Mo à 284 Ko installés, en passant à bend.

J'ai essayé de remplacer plusieurs de nos dépendances par des versions locales internalisées / personnalisées de ces packages et j'ai remplacé request par request-postman pour supprimer les avertissements de dépréciation. Cela semblait être une solution facile, qui nous permettrait plus tard de remplacer progressivement request-postman par une alternative plus légère.

Ensuite, j'ai appris que NPM est incroyablement bogué en ce qui concerne la gestion des packages locaux qui eux-mêmes reposent sur des packages locaux, ce qui a rendu notre environnement considérablement moins stable. Cela a vraiment ouvert une toute autre boîte de vers, j'ai donc dû annuler mes modifications et revenir à request , car cela ne valait tout simplement pas le temps et les efforts d'essayer de résoudre ce genre de problème à ce stade point dans le temps.

Pour l'instant, je ne vois pas d'autre alternative que de vivre avec les avertissements de dépréciation, car nous utilisons simplement trop de dépendances qui ont elles-mêmes request comme dépendance pour s'en débarrasser avec très peu de maux de tête. C'est malheureux et l'OMI n'aurait jamais dû arriver !

@csvan a dit que vous étiez "assez arrogant". C'est une expression beaucoup plus polie que celle que j'aurais utilisée.

Qui êtes-vous pour qualifier une personne d'"arrogante" ou pire, simplement parce que vous ne comprenez pas pourquoi les avertissements de dépréciation sont importants pour elle et ses projets ? !

Ce que je trouve arrogant, c'est simplement déprécier un projet dont dépendent des millions d'autres projets sans aucune bonne raison, au lieu de chercher un autre mainteneur pour prendre le relais. Et étant donné que l'équipe Postman dispose déjà d'un fork complet de request qui est activement maintenu, je ne peux pas imaginer qu'il aurait été très difficile de les convaincre de le faire.

Quelle est votre estimation, en millions d'USD, du coût mondial de cette décision de déprécier request ?

Zéro. Cela fonctionne aussi bien que jamais. Cela ne s'améliorera tout simplement pas.

Zéro. Cela fonctionne aussi bien que jamais. Cela ne s'améliorera tout simplement pas.

Connerie!

Si vous pensez que les avertissements d'obsolescence n'ont aucun impact sur les projets qui en dépendent, vous n'avez aucune idée de ce qu'implique l'obsolescence et à quoi ces messages sont destinés !

La dépréciation rend beaucoup de gens très nerveux, et pour cause. C'est ce que la dépréciation est censée faire !

Ah, pas de problème alors. Mes calculs au dos de l'enveloppe sont d'environ 30 millions de dollars américains, mais je suppose que je me suis trompé.

30 millions de dollars me semblent être une estimation très basse, compte tenu du nombre de packages qui dépendent directement ou indirectement de ce projet !

Je suis étonné et étonné du nombre de personnes ici qui pensent avoir droit au logiciel libre.

Je suis étonné et étonné du nombre de personnes ici qui pensent avoir droit au logiciel libre.

Je suis étonné et étonné du nombre de personnes qui pensent qu'elles n'ont aucune responsabilité quant à l'impact de leurs actions sur leurs utilisateurs simplement parce que leurs produits sont gratuits ou open source.

OMI, c'est une question de respect fondamental de traiter vos utilisateurs / clients de la même manière qu'ils paient pour utiliser votre application / bibliothèque ou qu'ils ne paient pas.

Désapprouveriez-vous un projet utilisé par des millions d'autres projets en tant que dépendance si les gens payaient pour cela à moins que vous n'ayez une très, très, très bonne raison pour cela (comme des projets dépendants qui se bloquent si les gens ne prennent aucune mesure dans temps)?

@jslegers Mon point exactement. Tellement droit ! Incroyable!

@jslegers Mon point exactement. Tellement droit ! Incroyable!

Pot...

Bouilloire...

Je ne vois rien de plus légitime que d'argumenter que les utilisateurs d'une manière ou d'une autre vous « doivent » de leur avoir donné des logiciels open source et qu'ils devraient se sentir « honorés » ou « reconnaissants » envers vous et donc n'avoir aucun droit de se plaindre. lorsque vos actions impactent directement leurs projets.

Bien sûr, maintenir un projet open source pendant des années nécessite beaucoup de travail acharné et de dévouement. Bien sûr, c'est quelque chose à admirer lorsque les gens sont prêts à le faire pendant leur temps libre sans aucune compensation financière. Mais ce n'est toujours pas une excuse pour agir comme il se doit et laisser vos utilisateurs dans le froid quand ils ont le plus besoin de vous et il existe plusieurs alternatives sans effort !

@CliffS

Personnellement, j'en ai profité pour faire évoluer progressivement mes forfaits. kraken-exchange, par exemple, est passé de 5,9 Mo à 284 Ko installés, en passant à bend.

Je viens de jeter un œil et le package.json fait toujours référence à la version de demande 2,88.0

Je viens de jeter un œil et le package.json fait toujours référence à la version de demande 2,88.0

@JonathanRowell Oui. Il est actuellement en cours de test avant de le pousser vers npm. La version v1.9.0 sera là d'ici la fin de la journée.

Mais ce n'est toujours pas une excuse pour agir comme il se doit et laisser vos utilisateurs dans le froid quand ils ont le plus besoin de vous et il existe plusieurs alternatives sans effort !

Exactement, c'est pourquoi nous avons des gens comme @jslegers prêts à mettre de côté quelques heures de leur temps libre chaque jour pour aider à la maintenance, répartir la charge de travail et faire avancer le projet, plutôt que de se plaindre d'un problème !

Oh, attendez.

Exactement, c'est pourquoi nous avons des gens comme @jslegers prêts à mettre de côté quelques heures de leur temps libre chaque jour pour aider à la maintenance, répartir la charge de travail et faire avancer le projet, plutôt que de se plaindre d'un problème !

Tort!

C'est pourquoi nous avons les sympathiques membres de l'équipe Postman , qui ont déjà leur propre fourchette request nommée postman-request , qui peut servir de remplacement complet pour request et qui est activement maintenu ! L'alternative de bon sens à la dépréciation de request serait de leur demander de prendre en charge la maintenance de request .

Au cas où les gens de Postman refuseraient pour une raison quelconque, request pourrait toujours recommander officiellement postman-request comme remplacement complet de la fonctionnalité dans l'avertissement de dépréciation, pour éviter que des ressources ne soient inutilement gaspillées par centaines - pas des milliers - de développeurs qui recherchent indépendamment un tel remplacement.

Alternativement, vous pouvez simplement annoncer officiellement l'abandon de la maintenance / support de request et le laisser mourir lentement et paisiblement sans avertissement de dépréciation, car il n'est vraiment pas nécessaire de déprécier OU de continuer la maintenance d'un package qui fonctionne parfaitement bien et n'est pas pas sur le point de casser dans un proche avenir.

L'une ou l'autre de ces 3 approches serait infiniment meilleure que l'approche actuelle et ne nécessiterait aucune ressource supplémentaire de la part d'aucune partie.

Je ne pense pas que se disputer pour savoir si l'un ou l'autre a droit à leurs attentes est constructif et n'aidera pas non plus à résoudre les problèmes qui se posent. Nous prenons et donnons tous, et coopérons les uns avec les autres dans l'espoir que nos propres problèmes peuvent être résolus plus facilement, mais personne ne peut forcer l'autre à agir contre sa volonté.

Je crois que les faits sont que a) le propriétaire actuel ne veut plus faire avancer le projet (parfaitement compréhensible), mais aussi que b) de nombreuses personnes ressentent beaucoup de douleur à cause de l'avertissement de dépréciation car la migration ne le sera pas se produisent immédiatement la plupart du temps (parfaitement compréhensible aussi).

Il me semble donc qu'un compromis raisonnable serait, à l' instar de ce @jslegers , que la propriété du projet soit transférée à une personne intéressée et disposée à le prendre, à supprimer l'avertissement de dépréciation pour le moment et à gérer le processus de dépréciation d'une manière qui soit plus doux pour les personnes affectées par le déménagement.

Alors, @mikeal , êtes-vous prêt à céder la propriété du projet à quelqu'un d'autre ?

Et est-ce que quelqu'un d'autre est prêt à s'en remettre à Mikeal pour résoudre le problème que les gens rencontrent avec l'avertissement émis ?

Outre la coopération pour la passation de la maîtrise d'ouvrage, aucun de nous ne peut parler pour les autres, leur dire de faire ceci ou cela ; on ne peut parler que pour soi.

un autre fait qui n'a pas été beaucoup mentionné dans ce fil est l'impact sur la sécurité du transfert de propriété d'un package aussi populaire. nous avons eu des incidents récents où un transfert de propriété était à un mauvais acteur et a entraîné une activité malveillante dans les nouvelles versions du package. des packages populaires comme celui-ci sont de bonnes cibles pour ce type d'acteur.

Je ne commenterai pas la fiabilité d'une équipe spécifique qui pourrait prendre la relève, mais il est important de reconnaître à quel point une telle suggestion est vraiment risquée. la dépréciation de ce package n'empêche pas les forks de continuer à maintenir ce package sous un nom différent, mais le changement de nom permet à un consommateur de prendre la décision de consommer ce fork plutôt que cela se produise automatiquement sans possibilité d'évaluer le risque pour leur projet.

un autre fait qui n'a pas été beaucoup mentionné dans ce fil est l'impact sur la sécurité du transfert de propriété d'un package aussi populaire. nous avons eu des incidents récents où un transfert de propriété était à un mauvais acteur et a entraîné une activité malveillante dans les nouvelles versions du package. des packages populaires comme celui-ci sont de bonnes cibles pour ce type d'acteur.

Évidemment, vous ne pouvez pas transférer la propriété à n'importe qui. Mais l'équipe Postman semble être un choix logique, car...

• Ils ont une réputation à protéger et ne peuvent donc pas se permettre de nuire au projet request en injectant du code malveillant dans le projet
• En tant que plate-forme de développement et de test d'API, devenir le mainteneur officiel d'un package NPM très populaire utilisé par bon nombre de leurs clients potentiels peut être un avantage marketing pour eux.
• Comme ils maintiennent déjà leur propre fork de request , cela ne devrait leur demander aucune ressource supplémentaire. Ils pourraient simplement fusionner leur fork dans request , et déplacer les ressources de leur propre fork (qui ne serait plus nécessaire) vers le repo officiel request

Évidemment, il n'y a aucune garantie qu'ils accepteront. Mais s'ils avaient du bon sens, ils sauteraient dessus immédiatement. Donc, à moins qu'un responsable de request n'ait déjà essayé de les contacter et puisse confirmer qu'ils ont en fait décliné cette proposition, cela vaut vraiment le coup, OMI !

il n'est vraiment pas nécessaire d'abandonner OU de continuer la maintenance d'un package qui fonctionne parfaitement et n'est pas sur le point de tomber en panne dans un avenir proche.

C'est tellement en arrière que je ne sais même pas par où commencer. Qu'un paquet ne soit pas maintenu et qu'il soit recommandé de l'éloigner est tout le point de dépréciation.
Le propriétaire vous fait savoir que vous accumulez une dette technique en l'utilisant pour que vous puissiez passer à autre chose. L'avantage d'une dépréciation officielle via npm est exactement que les gens en reçoivent une indication claire, plutôt que d'avoir à le découvrir des années plus tard (dans votre scénario "laissez-le mourir lentement") où il est probablement déjà trop tard pour envisager une migration en douceur.

Les colis largement utilisés et abandonnés par la suite ne meurent pas paisiblement. Ils meurent lorsque les personnes qui les utilisent commencent à s'éloigner dans la panique après que leur état non maintenu entraîne en fait la rupture des objets et l'ouverture de failles de sécurité.

Avouons-le, ni vous ni moi n'aurions probablement connu l'état de la demande sans l'avis de dépréciation. La grande majorité des utilisateurs non plus.

J'ai essayé d'installer angulaire sous Linux, puis sous Windows et dans les deux, je n'ai pas pu, après avoir exécuté la commande npm install -g @ angular / cli @ latest dans les deux, j'ai rencontré cette erreur

C:\Users\Hanzell>npm install -g @angular/cli@latest
npm WARN obsolète [email protected] : la demande a été obsolète, voir #3142
C:\Users\Hanzell\AppData\Roamingnpm\ng -> C:\Users\Hanzell\AppData\ Roamingnpmnode_modules@angular\cli\bin\ng

@angular/ cli @ Roamingnpmnode_modules@angular\cli
nœud ./bin/postinstall/script.js

• @angular/ [email protected]
  ajouté 260 packages de 205 contributeurs en 188.027s

Ensuite, j'ai créé le référentiel et cela est apparu

C:\Users\Hanzell\Desktop>ng nouveau
? Quel nom aimeriez-vous utiliser pour le nouvel espace de travail et le projet initial ? salut
? Souhaitez-vous ajouter un routage angulaire ? Non
? Quel format de feuille de style souhaitez-vous utiliser ? CSS
CRÉER hola/angular.json (3551 octets)
CRÉER hola/package.json (1281 octets)
CRÉER hola/README.md (1021 octets)
CRÉER hola/tsconfig.json (543 octets)
CRÉER hola/tslint.json (1953 octets)
CRÉER hola/.editorconfig (246 octets)
CRÉER hola/.gitignore (631 octets)
CREER hola/browserslist (429 octets)
CRÉER hola/karma.conf.js (1016 octets)

• Installation des packages...npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142g.spec.json (270 octets)
  npm ERR ! Fin inattendue de l'entrée JSON lors de l'analyse près de '...f8x\n2SbOSCsT+zdXwIaf'

npm ERR ! Un journal complet de cette course peut être trouvé dans:
npm ERR ! C:\Users\Hanzell\AppData\Roamingnpm-cache_logs\2020-03-01T05_15_55_441Z-debug.log
× L'installation du package a échoué, voir ci-dessus.
Le workflow schématique a échoué. Voir au dessus.
CRÉER hola/src/assets/.gitkeep (0 octets

aider!

Vérifiez la mise à jour de npm et plus tard l'installation de npm dans le projet angulaire

C'est tellement en arrière que je ne sais même pas par où commencer. Qu'un paquet ne soit pas maintenu et qu'il soit recommandé de l'éloigner est tout le point de dépréciation.

Le fait qu'un package n'est pas maintenu et DOIT être déplacé avant la fin d'une période de grâce est le point de dépréciation.

S'il n'y a pas d'obligation de déménager avant un moment précis, vous ne devriez pas désapprouver... du moins pas à moins que vous ne puissiez proposer un remplacement (comme postman-request dans ce cas) !

La différence peut être subtile, mais la conséquence est importante. Vous gaspillez les ressources de plusieurs milliers d'entreprises sans raison valable en les dépréciant, ce qui pourrait être évité en mettant simplement fin à la maintenance et en en restant là !

un autre fait qui n'a pas été beaucoup mentionné dans ce fil est l'impact sur la sécurité du transfert de propriété d'un package aussi populaire. nous avons eu des incidents récents où un transfert de propriété était à un mauvais acteur et a entraîné une activité malveillante dans les nouvelles versions du package. des packages populaires comme celui-ci sont de bonnes cibles pour ce type d'acteur.

... déprécier ce paquet n'empêche pas forks de continuer à maintenir ce paquet sous un nom différent

Assez juste; Je suppose que nous pouvons attendre un peu pour avoir des nouvelles des Postman et évaluer si le transfert vers eux est viable ; mais sinon, les fourches semblent être la voie à suivre, alors.

Non, vous ne faites perdre de temps à personne en précisant qu'une de leurs dépendances est désormais abandonnée et presque certainement source de dette technique. C'est tout le contraire qui est vrai, et toute la discussion sur cette question en est la preuve - une discussion qui n'aurait probablement pas eu lieu de si tôt sans la dépréciation.

Non, vous ne faites perdre de temps à personne en précisant qu'une de leurs dépendances est désormais abandonnée et presque certainement source de dette technique.

Ce n'est pas parce qu'un projet est abandonné qu'il doit être remplacé par autre chose.

Surtout pour les projets qui utilisent plusieurs dépendances qui utilisent tous request comme dépendance eux-mêmes, le gain potentiel d'essayer de remplacer request par quelque chose d'autre n'est même pas proche de l'effort requis pour y parvenir !

une discussion qui n'aurait probablement pas eu lieu de si tôt sans la dépréciation.

Cette discussion n'aurait pas été nécessaire sans la dépréciation.

https://xkcd.com/386/

Oui, ce serait le cas à un moment donné, avec ou sans dépréciation. Ce point est toujours mieux atteint plus tôt que des années plus tard lorsque les effets d'un paquet non maintenu commencent à se faire sentir.

Quoi qu'il en soit, j'abandonne. S'amuser.

« Tout est modifiable, tout apparaît et disparaît ; il n'y a pas de paix bienheureuse tant que l'on n'a pas dépassé l'agonie de la vie et de la mort.

- Bouddha Gautama

@mikeal Vous êtes un anti-émeute... merci pour le rappel !

Avant d'entrer dans les détails et le raisonnement, je vais aller droit au but. La chose la plus précieuse que request puisse faire pour l'écosystème JavaScript est de passer en mode maintenance et d'arrêter d'envisager de nouvelles fonctionnalités ou des versions majeures.

Mes excuses d'avance aux autres committers sur request qui ont fait de leur mieux pour l'améliorer, mais c'est pour le mieux.

2009

La première version de request était l'un des premiers modules jamais créés pour l'écosystème Node.js. Les premières versions ont été écrites dans des API antérieures à l'interface de rappel standard, aux flux, aux node_modules et à npm. Au cours des premières années, request et Node.js ont évolué ensemble, chacun apprenant l'un de l'autre. Au fur et à mesure que Node.js s'améliorait et migrait les interfaces principales, la demande en a fait autant. Au fur et à mesure que la demande adoptait des modifications de la bibliothèque et des flux http de base, elle a également informé des améliorations telles que l'événement pipe (qui a permis le proxy à une ligne de request ) et l'une des nombreuses réécritures de Core http (le celui que je devais écrire).

npm

request été l'un des premiers modules ajoutés au registre npm. Au fur et à mesure que npm augmentait, la dépendance à l'égard de request s'est également accrue. Même maintenant, alors que npm est beaucoup plus utilisé pour le front-end que pour le back-end, request reste l'un des modules les plus dépendants du registre. Au moment où j'écris ceci, 41K modules dépendent de la demande et sont téléchargés 14 millions de fois par semaine.

La place de request dans l'écosystème Node.js n'est plus celle d'un innovateur mais celle d'un titulaire. Si vous recherchez sur Google comment faire quelque chose avec HTTP dans Node.js, les exemples montreront probablement request tant que client et express tant que serveur. Cela a deux effets notoirement mauvais.

Il est beaucoup plus difficile pour les nouvelles bibliothèques qui accomplissent des tâches similaires d'être adoptées en raison de la position de titulaire que détient request dans l'écosystème. Il est également très difficile de modifier la demande de manière significative, car non seulement le changement pourrait ne pas être adopté par la majorité de ses personnes à charge, mais il le mettrait en décalage avec les milliers de billets de blog et les réponses de débordement de pile qui utilisent request .

JavaScript moderne

Les dernières années ont été dramatiques en JavaScript. Les fonctionnalités dont les gens parlaient depuis des années sont passées d'idées à des normes, à des fonctionnalités sur lesquelles vous pouvez compter de manière fiable dans la plupart des environnements. La vitesse à laquelle ceux-ci ont été adoptés est stupéfiante, principalement grâce à la mise à jour automatique des navigateurs et à un calendrier de publication agressif de Node.js.

Les modèles au cœur de request sont obsolètes. Quelques personnes pourraient contester cette évaluation, et je sais qui elles sont donc je ne serai pas surpris, mais c'est vrai. J'ai souvent été sceptique quant à l'impact que certaines de ces fonctionnalités auraient pour me retrouver à les adopter en gros peu de temps après qu'elles ne soient disponibles que dans la dernière version de Node.js.

Il y a une transition qui se produit maintenant dans l'écosystème vers ces modèles. À quel point ce sera désordonné est encore en suspens et je ne vais pas essayer de lire les feuilles de thé et de comprendre à quoi ressemble l'avenir à cet égard. La question pour request est « Essayons-nous de survivre à cette transition ? » Il y a un an, je pensais que la réponse était évidente et que nous le ferions, mais maintenant je suis convaincu du contraire.

Une version de request écrite pour vraiment adopter ces nouveaux modèles de langage est, en fait, un nouveau module. J'ai déjà un peu exploré request de toutes les manières imaginables. Quelle est la valeur d'une version de request qui est incompatible avec les anciens modèles mais qui n'embrasse pas complètement les nouveaux ? Quel est l'intérêt d'être partiellement compatible quand il y a tout un monde de nouveaux modules, écrits par de nouveaux développeurs, qui repensent ces problèmes avec ces modèles à l'esprit ?

La meilleure chose pour ces nouveaux modules est que request disparaissent lentement, devenant finalement juste une autre mémoire de cette pile héritée. Prendre la position actuelle de request et l'exploiter pour une plus grande part de la prochaine génération de développeurs serait un mauvais service pour ces développeurs car cela les éloignerait de meilleurs modules qui n'ont pas le fardeau de request L'histoire de

Mode de Maintenance

Voici le plan.

• request n'acceptera plus de nouvelles fonctionnalités.
• request cessera d'envisager des changements de rupture.
• Les commiters qui sont encore actifs essaieront de fusionner les correctifs en temps opportun, sans promesse cependant.

• Les versions seront entièrement automatisées, toute fusion dans le master sera publiée. J'ai déjà construit ceci pour d' autres projets en utilisant GitHub Actions .

  • Nous allons devoir supprimer les collaborateurs inactifs et appliquer 2fa, car les droits de validation deviendront effectivement des droits de publication npm.

Que se passe-t-il si nous le supprimons simplement ? ces dépendances sont une tuerie !

@grikard Je suis d'accord avec ça - bonne analyse. Mais sans vouloir paraître trivial - c'est une vraie question - les Américains épellent-ils le pluriel de « feuille » comme feuilles ? J'ai prêté des "feuilles".

feuilles est pluriel pour feuille :)

Installation des packages...npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142
si quelqu'un d'autre va ici parce que vous avez une erreur sur
ng new my-app
réessayer
sudo ng new my-app
heureux piratage

Bonjour Comment résoudre cette erreur ? https://github.com/request/request/issues/3142

Bonjour Comment résoudre cette erreur ? #3142

Quelle erreur ?

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

Le mer. 11 mars 2020, 20:23 Cliff Stanford [email protected]
a écrit:

Bonjour Comment résoudre cette erreur ? #3142
https://github.com/request/request/issues/3142

Quelle erreur ?

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/request/request/issues/3142#issuecomment-597602350 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AN6OSLTSIY5LZVUEOX3JWHDRG57FNANCNFSM4HCP6LRA
.

Je ne peux pas terminer mon projet à cause de ça... et c'est pour ce soir. Quelqu'un peut-il aider à résoudre ce problème dans la demande ??

@AELDREI Ce n'est pas une erreur. La dépréciation n'est qu'un avertissement/une information, tout fonctionne toujours.
@valentina-js "Ceci" n'est qu'un avertissement/une information, cela ne peut donc pas être la cause de votre incapacité à terminer votre projet. Si vous avez un problème, il doit avoir une autre cause. Essayez de rechercher un message d'erreur réel et voyez si un problème similaire a été signalé. Sinon, ouvrez-en un et décrivez votre erreur en détail.

Oh non. Ce n'était pas nécessaire. Déchirure

Nouveau produit

npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142

S'il vous plaît, résolvez cela ! Je ne sais pas ce que je fais mal :

npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142
npm WARN checkPermissions Accès en écriture manquant à /usr/local/lib/node_modules
npm ERR ! code EACCES
npm ERR ! accès aux appels système
npm ERR ! chemin /usr/local/lib/node_modules
npm ERR ! errno -13
npm ERR ! Erreur : EACCES : autorisation refusée, accès '/usr/local/lib/node_modules'
npm ERR ! [Erreur : EACCES : autorisation refusée, accès '/usr/local/lib/node_modules'] {
npm ERR ! pile : "Erreur : EACCES : autorisation refusée, accès '/usr/local/lib/node_modules'",
npm ERR ! numéro d'erreur : -13,
npm ERR ! code : 'EACCES',
npm ERR ! syscall : 'accès',
npm ERR ! chemin : '/usr/local/lib/node_modules'
npm ERR ! }
npm ERR !
npm ERR ! L'opération a été rejetée par votre système d'exploitation.
npm ERR ! Il est probable que vous n'ayez pas les autorisations pour accéder à ce fichier en tant qu'utilisateur actuel
npm ERR !
npm ERR ! Si vous pensez qu'il s'agit d'un problème d'autorisation, veuillez vérifier
npm ERR ! autorisations du fichier et de ses répertoires contenant, ou essayez d'exécuter
npm ERR ! la commande à nouveau en tant que root/administrateur.

npm ERR ! Un journal complet de cette course peut être trouvé dans:
npm ERR ! /Users/Hazem/.npm/_logs/2020-03-15T16_16_03_301Z-debug.log

@hazemgg NPM n'a pas d'accès en écriture à node_modules. Il n'y a rien de mal avec request qui bloque npm install . Essayez de l'exécuter avec sudo .

Merci pour votre réponse rapide, cela a fonctionné comme un charme!

Alors je pense que je deviens fou ! J'ai dû lire README au moins 20 fois. Tout ce programme dépasse mes connaissances de base en html...

_Comment obtenir des commentaires youtube ?_
Dois-je exécuter youtube-comment-scraper en nœud ? borne de base ? ou commande ?
la réponse du nœud est ...
la réponse du terminal est que le titre change mais rien ne se passe

_Et si je souhaite avoir un fichier csv ?_
est la commande : youtube-comment-scraper --outputFile youtubecomments.csv --stdout --format csv correct?

_Ballpark combien de temps faudrait-il pour exécuter le programme pour obtenir, disons, un millier de commentaires ?_

@hazemberg Les deux. Voir https://www.npmjs.com/package/youtube-comment-scraper#usage pour l'utilisation de la ligne de commande et https://www.npmjs.com/package/youtube-comment-scraper#method pour l'utilisation programmatique. Vous pouvez également exécuter npx youtube-comment-scraper avec Node.js installé dans la ligne de commande pour accéder à la CLI.

@Richienb Merci encore pour l'info ! Je vais les étudier et j'espère réussir !

Oui, il semble que tout le monde fasse quelque chose de mal. On m'a dit qu'il n'y aurait aucun coût à la décision de déprécier request .

Il n'y a jamais de coût zéro !

Je suis confronté à un problème avec la création du tunnel de sauce.
En utilisant le service de sauce suivant.
npm install -g wdio-sauce-service
25hnpm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142
25h

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

+ [email protected]

Obtention de l'erreur ci-dessous en essayant de créer le tunnel de sauce.
Impossible de démarrer Sauce Connect. Signal de code de sortie 1 : nul
Un service a échoué dans le hook 'onPrepare'
Erreur : impossible de démarrer Sauce Connect. Signal de code de sortie 1 : nul
à ChildProcess.(/usr/local/lib/node_modules/wdio-sauce-service/node_modules/sauce-connect-launcher/lib/sauce-connect-launcher.js:566:12)
à ChildProcess.emit (events.js:198:13)
à ChildProcess.EventEmitter.emit (domain.js:448:20)
à Process.ChildProcess._handle.onexit (internal/child_process.js:248:12)

Soyez respectueux et évitez de poster des questions sérieuses. Seuls les mèmes d'environ request .

@anton-bot laisse tomber et continue ta vie.

Soyez respectueux et évitez de poster des questions sérieuses. Seuls les mèmes d'environ request .

@anton-bot laisse tomber et continue ta vie.

Revenons au sérieux, maintenant que request a été "officiellement" déprécié via npm deprecate , maintenant _chaque_ utilisateur en amont reçoit de nouveaux avertissements à ce sujet.

Pouvons-nous considérer cela un instant ? Je pense que cela a provoqué une panique excessive. Non seulement cela, mais les systèmes automatisés qui valident leurs journaux font désormais référence à ce problème b/c de la clé du problème dans l'avertissement de dépréciation.

Je suis d'accord pour dire que request a mûri jusqu'à l'obsolescence, mais s'il fonctionne toujours bien et a des centaines de dépendances avec différents niveaux d'entretien, il ne devrait peut-être pas être officiellement obsolète dans npm mais plutôt un gros avertissement dans la police maximale dans le fichier README ?

Et puis un jour chacun de ces utilisateurs dira : "Pourquoi n'avons-nous pas été prévenus à ce sujet !?" ??

mais si cela fonctionne toujours bien et a des centaines de dépendances avec différents niveaux d'entretien, peut-être ne devrait-il pas être officiellement déprécié dans npm mais plutôt un gros avertissement dans la police maximale dans le fichier README ?

Le problème est qu'essentiellement _personne_ ne les lit. 99% des personnes qui paniquent maintenant n'auraient même jamais su que la demande était obsolète à moins que NPM ne les en avertisse. _Personne_ s'assoit et parcourt le README de _toutes_ ses dépendances pour déterminer lesquelles ne sont plus maintenues - jusqu'à ce qu'il soit trop tard.

Je me répète, mais le scénario que vous proposez signifie essentiellement que les gens découvriront à la place que la demande est obsolète - lorsqu'elle finit par casser des choses et provoquer des failles de sécurité en raison du fait qu'il s'agit d'un ancien service non entretenu dans un environnement moderne. Lorsque cela se produira, les gens devront plutôt chercher une alternative, plutôt que d'avoir la chance - comme c'est le cas actuellement - d'en rechercher une tant que la demande est toujours stable et utilisable, ce qui est probablement une autre année au moins.

La dépréciation de la demande était la chose responsable à faire, et elle ne sera pas annulée. La communauté devrait concentrer ses efforts sur l'accord sur une bonne alternative et/ou une fourchette plutôt que d'essayer de faire renverser cela. Passez.

WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142 .
Comment puis-je corriger cette erreur ?

@mrmehi Pouvez-vous s'il vous plaît lire le tout premier message ici ?

Ce n'est pas une erreur. Soit vous dépendez directement de la demande (et vous devez ensuite passer à une autre bibliothèque, par exemple got ou bent ), soit vous en dépendez transitivement via l'une de vos dépendances - puis mettez-la à jour si elles déjà déplacé, ou envoyez-leur un ping pour passer à autre chose.

@kibertoad Je suis vraiment confus, que dois-je faire maintenant ?
ça arrive quand j'essaye de télécharger expo.io

@kibertoad Je suis vraiment confus, que dois-je faire maintenant ?
ça arrive quand j'essaye de télécharger expo.io

Vous n'avez rien à faire. Ce n'est pas une erreur, c'est un avertissement. C'est ce que la partie "WARN" du journal indique.
Vous _pourriez_ informer expo.io qu'ils pourraient vouloir commencer à chercher des alternatives à request , car il est obsolète et pourrait donc un jour cesser de fonctionner correctement.
Mais ils semblent déjà en être conscients, comme vous pouvez le voir ici :
https://github.com/expo/expo-cli/issues/1659

Microsoft compte toujours sur ce package. appcenter-cli donne cet avertissement de dépréciation lors de l'installation :

npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142

Compte tenu des antécédents de l'équipe AppCenter, il semble peu probable que cela change de si tôt. Nos journaux de construction regorgent d'avertissements concernant les packages qui ont été dépréciés il y a plus d'un an dans certains cas.

S'il vous plaît, quelqu'un peut m'aider. Je rencontre des difficultés lors de l'installation de expo-cli --global.
j'ai installé node, git. j'écris la commande en tant que npm install expo-cli --global mais je suis confronté au problème suivant :
"npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142
[..................] | fetchMetadata : WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142 "".
ce que je reçois cette erreur. veuillez me répondre comment résoudre ce problème.

@mrmehi Pouvez-vous s'il vous plaît lire le tout premier message ici ?

Ce n'est pas une erreur. Soit vous dépendez directement de la demande (et vous devez ensuite passer à une autre bibliothèque, par exemple got ou bent ), soit vous en dépendez transitivement via l'une de vos dépendances - puis mettez-la à jour si elles déjà déplacé, ou envoyez-leur un ping pour passer à autre chose.

s'il vous plaît pouvez-vous m'aider à résoudre ce problème? je suis confronté au problème.

@lemessur Il s'avère que les responsables ne savaient tout simplement pas que cette demande était obsolète. Voir https://github.com/microsoft/appcenter-cli/pull/758#issuecomment -603667106

Quelqu'un, s'il vous plaît, mettez ceci en haut du commentaire sur le problème principal :

Avis de dépréciation

Si vous obtenez WARN deprecated [email protected]: request has been deprecated, see #3142 en essayant d'installer vos dépendances, soyez assuré qu'il ne s'agit request ) doit migrer vers une autre bibliothèque. Voir : https://github.com/request/request/issues/3143

@alijatoi
Voir https://github.com/request/request/issues/3142#issuecomment-604126783

@Richienb
Voir #3142 (commentaire)

Alors que dois-je faire maintenant. s'il vous plaît pouvez-vous m'aider à résoudre ce problème?

@Richienb
Voir #3142 (commentaire)

Je suis nouveau sur github et je ne comprends pas quoi faire. pouvez-vous s'il vous plaît me dire étape par étape comment puis-je résoudre mon problème? à la recherche de votre réponse rapide.

@alijatoi expo-cli utilise request donc sa dépendance doit être modifiée.

@Richienb Alors que dois-je faire maintenant ? dois-je attendre ou existe-t-il un autre moyen d'installer l'expo-cli.
aidez moi s'il vous plait j'attends.
Merci

@alijatoi Créez un problème et/ou attendez.

@Richienb merci pour votre réponse.
il n'y a pas d'autre moyen d'installer expo cli ?

@alijatoi non

les gars, si vous rencontrez des problèmes, installez expo-cli avec npm à cause du message obsolète : installez laine puis laine installez expo-cli

@caio-vinicius Cela ne fonctionne que parce que fil n'affiche l'avertissement qu'une seule fois et continuera de l'afficher lors de la régénération du fichier de verrouillage.

les gars, si vous rencontrez des problèmes, installez expo-cli avec npm à cause du message obsolète : installez laine puis laine installez expo-cli

@caio-vinicius oui j'ai fait l'installation en utilisant install fil puis fil install expo-cli globlly mais après l'installation, lorsque je vérifie la version d'expo cli, cela pose problème que expo ne définit aucune commande interne ou externe

@alijatoi s'il vous plaît assurez-vous que vous utilisez la syntaxe correcte lors de l'utilisation de fil pour installer globalement.

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

Cependant, @alijatoi , une installation interrompue par un avertissement de dépréciation est presque certainement un problème avec votre environnement ou le package que vous essayez d'installer. Ce n'est pas spécifique à la demande et rien à signaler ici.

Je suis un peu en retard pour la fête mais ce serait bien d'ajouter une petite liste d'alternatives afin que les gens puissent les utiliser pour remplacer le request , comme nodejs construit dans http.ClientRequest . Merci.

uuuh https://github.com/request/request/issues/3143

F

Je suis d'accord avec tout ce que vous avez dit sur la forme, la compatibilité et le progrès, mais
Je ne vois pas pourquoi [email protected] ne peut pas le faire avec des changements de rupture. Après tout, c'est l'idée derrière semver ...

De nombreuses autres bibliothèques ont adopté les nouveaux modèles et capacités, et ont donc rompu la compatibilité et augmenté leur majeure.

Même s'il s'agit d'un tout nouveau module - le nom représente la crédibilité et
l'expérience des leçons apprises, que je suis triste de voir disparaître.

Intéressé d'en savoir plus à ce sujet.

Eh bien, merci pour le trajet et tout le travail acharné que vous avez fourni. 👍

Vous mon seigneur, êtes un héros.

Je comprends la raison pour laquelle cela fait que JS/Node (en général) progresse un peu plus vite.

Vous avez fait "presque" autant, pour l'espace NodeJS que jQuery l'a fait pour l'espace navigateur/DOM. Vous avez fait un plaisir de travailler avec TCP, et c'est essentiel pour le développement back-end.

Je vous remercie pour cela.

Prends soin.

Alors, quel est le guide sur la manière alternative de faire une demande https pour moi qui est nouveau pour le développement back-end avec node ?

@OluwafemiAdesegha https://github.com/request/request/issues/3143

Merci Cliff. Jeter un coup d'oeil.

NPM WARN Registre avertissement inattendu pour https://registry.npmjs.org/ : Divers Attention EINTEGRITY: sha512-7G3s83fOoweLlAsvR3wtw4DnepkrY + / FxmYxk1XnfAjE9xnoWRy9cLHWCywcc6l6018X1RdNxpJdtqX9WQAEXw == contrôle d'intégrité échoué lors de l' utilisation SHA512: voulu sha512-7G3s83fOoweLlAsvR3wtw4DnepkrY + / FxmYxk1XnfAjE9xnoWRy9cLHWCywcc6l6018X1RdNxpJdtqX9WQAEXw == mais a obtenu SHA512-NhZAWqNqTzZaAfgJYp0NlbBDUX8BMyOmobe3kYnymXfSxDgaiej4nP6N3aLVDtBTPHOfivySRs + AVsca0JgrTQ ==. (20905 octets)
Registre npm WARN Utilisation de données obsolètes de https://registry.npmjs.org/ en raison d'une erreur de demande lors de la revalidation.
npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142
npm ERR ! code EINTÉGRITÉ
npm ERR ! errno ÉINTÉGRITÉ
npm ERR ! Corps de réponse invalide tout en essayant de chercher https://registry.npmjs.org/uuid : Vérification de l' intégrité a échoué pour sha512-7G3s83fOoweLlAsvR3wtw4DnepkrY + / FxmYxk1XnfAjE9xnoWRy9cLHWCywcc6l6018X1RdNxpJdtqX9WQAEXw == (C: \ Utilisateurs MULAMBA SERGIO \ AppData \ Roamingnpm-cache_cacache \ contenu v2 \ SHA512 \ec\6d\ecf377cea3078b940b2f477c2dc380e77a992b63efc5c666319355e77c08c4f719e8591cbd70b1d60b2c1c73a97ad35f17d5174dc6925db6a5fd5900045f)

npm ERR ! Un journal complet de cette course peut être trouvé dans:
npm ERR ! C:\Users\MULAMBA SERGIO\AppData\Roamingnpm-cache_logs\2020-04-03T22_54_57_842Z-debug.log

npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142
npm WARN obsolète [email protected] : cette version a été obsolète conformément à la politique de support hapi (hapi.im/support). Veuillez effectuer une mise à niveau vers la dernière version pour obtenir les meilleures fonctionnalités, corrections de bogues et correctifs de sécurité. Si vous ne parvenez pas à mettre à niveau pour le moment, une assistance payante est disponible pour les anciennes versions (hapi.im/commercial).
npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142
npm WARN obsolète [email protected] : core-js@<3 n'est plus maintenu et son utilisation n'est pas recommandée en raison du nombre de problèmes. Veuillez mettre à niveau vos dépendances vers la version actuelle de core-js@3.
npm WARN obsolète [email protected] : cette version a été obsolète conformément à la politique de support hapi (hapi.im/support). Veuillez effectuer une mise à niveau vers la dernière version pour obtenir les meilleures fonctionnalités, corrections de bogues et correctifs de sécurité. Si vous ne parvenez pas à mettre à niveau pour le moment, une assistance payante est disponible pour les anciennes versions (hapi.im/commercial).
npm WARN obsolète [email protected] : cette version a été obsolète conformément à la politique de support hapi (hapi.im/support). Veuillez effectuer une mise à niveau vers la dernière version pour obtenir les meilleures fonctionnalités, corrections de bogues et correctifs de sécurité. Si vous ne parvenez pas à mettre à niveau pour le moment, une assistance payante est disponible pour les anciennes versions (hapi.im/commercial).
npm WARN obsolète [email protected] : cette version a été obsolète conformément à la politique de support hapi (hapi.im/support). Veuillez effectuer une mise à niveau vers la dernière version pour obtenir les meilleures fonctionnalités, corrections de bogues et correctifs de sécurité. Si vous ne parvenez pas à mettre à niveau pour le moment, une assistance payante est disponible pour les anciennes versions (hapi.im/commercial).
npm WARN obsolète [email protected] : ce module a été déplacé et est désormais disponible sur @hapi/topo. Veuillez mettre à jour vos dépendances car cette version n'est plus maintenue et peut contenir des bogues et des problèmes de sécurité.
npm WARN obsolète [email protected] : ce module a été déplacé et est désormais disponible sur @hapi/hoek. Veuillez mettre à jour vos dépendances car cette version n'est plus maintenue et peut contenir des bogues et des problèmes de sécurité.
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 facultatif SAUT DE DÉPENDANCE OPTIONNELLE : @expo/[email protected] (node_modules\expo-cli\node_modules\@expo\traveling-fastlane-darwin) :
npm WARN notsup SAUT DE DÉPENDANCE OPTIONNELLE : Plate-forme non prise en charge pour @expo/[email protected] : recherché {"os":"darwin","arch":"any"} (actuel : {"os":"" win32","arch":"x64"})
npm WARN facultatif SAUT DE DÉPENDANCE OPTIONNELLE : @expo/[email protected] (node_modules\expo-cli\node_modules\@expo\ngrok-bin\node_modules\@expo\ngrok-bin-linux-arm) :
npm WARN notsup SAUT DE DÉPENDANCE OPTIONNELLE : Plate-forme non prise en charge pour @expo/[email protected] : recherché {"os":"linux","arch":"arm"} (actuel : {"os" : "win32","arch":"x64"})
npm WARN facultatif SAUT DE DÉPENDANCE OPTIONNELLE : @expo/[email protected] (node_modules\expo-cli\node_modules\@expo\ngrok-bin\node_modules\@expo\ngrok-bin-darwin-ia32) :
npm WARN notsup Ignorer la dépendance facultative : plate-forme non prise en charge pour @expo/[email protected] : recherché {"os":"darwin","arch":"ia32"} (actuel : {"os" : "win32","arch":"x64"})
npm WARN facultatif SAUT DE DÉPENDANCE OPTIONNELLE : @expo/[email protected] (node_modules\expo-cli\node_modules\@expo\ngrok-bin\node_modules\@expo\ngrok-bin-freebsd-x64) :
npm WARN notsup SAUT DE DÉPENDANCE OPTIONNELLE : plate-forme non prise en charge pour @expo/[email protected] : recherché {"os":"freebsd","arch":"x64"} (actuel : {"os" : "win32","arch":"x64"})
npm WARN facultatif SAUT DE DÉPENDANCE OPTIONNELLE : @expo/[email protected] (node_modules\expo-cli\node_modules\@expo\ngrok-bin\node_modules\@expo\ngrok-bin-freebsd-ia32) :
npm WARN notsup Ignorer la dépendance facultative : plate-forme non prise en charge pour @expo/[email protected] : recherche {"os":"freebsd","arch":"ia32"} (actuel : {"os" : "win32","arch":"x64"})
npm WARN facultatif SAUT DE DÉPENDANCE OPTIONNELLE : @expo/[email protected] (node_modules\expo-cli\node_modules\@expo\ngrok-bin\node_modules\@expo\ngrok-bin-linux-ia32) :
npm WARN notsup Ignorer la dépendance facultative : plate-forme non prise en charge pour @expo/[email protected] : recherché {"os":"linux","arch":"ia32"} (actuel : {"os" : "win32","arch":"x64"})
npm WARN facultatif SAUT DE DÉPENDANCE OPTIONNELLE : @expo/[email protected] (node_modules\expo-cli\node_modules\@expo\ngrok-bin\node_modules\@expo\ngrok-bin-linux-x64) :
npm WARN notsup IGNORER LA DÉPENDANCE OPTIONNELLE : plate-forme non prise en charge pour @expo/[email protected] : recherché {"os":"linux","arch":"x64"} (actuel : {"os" : "win32","arch":"x64"})
npm WARN facultatif SAUT DE DÉPENDANCE OPTIONNELLE : @expo/[email protected] (node_modules\expo-cli\node_modules\@expo\ngrok-bin\node_modules\@expo\ngrok-bin-darwin-x64) :
npm WARN notsup Ignorer la dépendance facultative : plate-forme non prise en charge pour @expo/[email protected] : recherché {"os":"darwin","arch":"x64"} (actuel : {"os" : "win32","arch":"x64"})
npm WARN facultatif SAUT DE DÉPENDANCE FACULTATIVE : @expo/[email protected] (node_modules\expo-cli\node_modules\@expo\ngrok-bin\node_modules\@expo\ngrok-bin- win32-ia32):
npm WARN notsup Ignorer la dépendance facultative : plate-forme non prise en charge pour @expo/[email protected] : recherché {"os":"win32","arch":"ia32"} (actuel : {"os":"win32","arch":"x64"})
npm WARN facultatif SAUT DE DÉPENDANCE OPTIONNELLE : @expo/[email protected] (node_modules\expo-cli\node_modules\@expo\ngrok-bin\node_modules\@expo\ngrok-bin-sunos-x64) :
npm WARN notsup Ignorer la dépendance facultative : plate-forme non prise en charge pour @expo/[email protected] : recherche {"os":"sunos","arch":"x64"} (actuel : {"os" : "win32","arch":"x64"})
npm WARN facultatif SAUT DE DÉPENDANCE OPTIONNELLE : @expo/[email protected] (node_modules\expo-cli\node_modules\@expo\ngrok-bin\node_modules\@expo\ngrok-bin-linux-arm64) :
npm WARN notsup SAUT DE DÉPENDANCE OPTIONNELLE : Plate-forme non prise en charge pour @expo/[email protected] : recherché {"os":"linux","arch":"arm64"} (actuel : {"os" : "win32","arch":"x64"})
npm WARN facultatif SAUT DE DÉPENDANCE FACULTATIVE : fsevents@^1.2.7 (node_modules\expo-cli\node_modules\chokidar\node_modules\fsevents) :
npm WARN notsup IGNORER LA DÉPENDANCE OPTIONNELLE : plate-forme non prise en charge pour [email protected] : recherché {"os":"darwin","arch":"any"} (actuel : {"os":"win32","arch": "x64"})
npm WARN @expo/[email protected] nécessite un homologue de sharp-cli@^1.10.0 mais aucun n'est installé. Vous devez installer vous-même les dépendances de pairs.
npm WARN facultatif SAUT DE DÉPENDANCE FACULTATIVE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\abbrev) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\abbrev' -> 'C:\ Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.abbrev.DELETE'
npm WARN facultatif SAUT DE DÉPENDANCE FACULTATIVE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\ansi-regex) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez '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 facultatif IGNORER LA DÉPENDANCE OPTIONNELLE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\aproba) :
npm WARN enoent Ignorer la dépendance facultative : ENOENT : aucun fichier ou répertoire de ce type, renommez 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\aproba' -> 'C:\ Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.apoba.DELETE'
npm WARN facultatif IGNORER LA DÉPENDANCE FACULTATIVE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\balanced-match) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\balanced-match' -> 'C :\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.balanced-match.DELETE'
npm WARN facultatif SAUT DE DÉPENDANCE OPTIONNELLE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\chownr) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\chownr' -> 'C:\ Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.chownr.DELETE'
npm WARN facultatif SAUT DE DÉPENDANCE FACULTATIVE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\code-point-at) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez '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 facultatif SAUT DE DÉPENDANCE OPTIONNELLE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\concat-map) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez '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 facultatif SAUT DE DÉPENDANCE FACULTATIVE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\console-control-strings) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez '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 facultatif IGNORER LA DÉPENDANCE FACULTATIVE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\core-util-is) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez '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 facultatif SAUT DE DÉPENDANCE FACULTATIVE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\deep-extend) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez '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 facultatif SAUT DE DÉPENDANCE FACULTATIVE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\delegates) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\delegates' -> 'C:\ Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.delegates.DELETE'
npm WARN facultatif SAUT DE DÉPENDANCE FACULTATIVE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\detect-libc) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez '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 facultatif SAUT DE DÉPENDANCE FACULTATIVE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\fs.realpath) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez '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 facultatif SAUT DE DÉPENDANCE FACULTATIVE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\has-unicode) :
npm WARN enoent Ignorer la dépendance facultative : ENOENT : aucun fichier ou répertoire de ce type, renommez '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 facultatif SAUT DE DÉPENDANCE FACULTATIVE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\inherits) :
npm WARN enoent Ignorer la dépendance facultative : ENOENT : aucun fichier ou répertoire de ce type, renommez 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\inherits' -> 'C:\ Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.inherits.DELETE'
npm WARN facultatif SAUT DE DÉPENDANCE OPTIONNELLE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\ini) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\ini' -> 'C:\ Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.ini.DELETE'
npm WARN facultatif SAUT DE DÉPENDANCE OPTIONNELLE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\isarray) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\isarray' -> 'C:\ Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.isarray.DELETE'
npm WARN facultatif SAUT DE DÉPENDANCE OPTIONNELLE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\minimist) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\minimist' -> 'C:\ Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.minimist.DELETE'
npm WARN facultatif SAUT DE DÉPENDANCE FACULTATIVE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\ms) :
npm WARN enoent Ignorer la dépendance facultative : ENOENT : aucun fichier ou répertoire de ce type, renommez 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\ms' -> 'C:\ Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.ms.DELETE'
npm WARN facultatif SAUT DE DÉPENDANCE FACULTATIVE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\npm-normalize-package-bin) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez '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 facultatif SAUT DE DÉPENDANCE FACULTATIVE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\number-is-nan) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez '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 facultatif SAUT DE DÉPENDANCE FACULTATIVE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\object-assign) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez '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 facultatif SAUT DE DÉPENDANCE OPTIONNELLE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\os-homedir) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez '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 facultatif SAUT DE DÉPENDANCE OPTIONNELLE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\os-tmpdir) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez '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 facultatif SAUT DE DÉPENDANCE FACULTATIVE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\path-is-absolute) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez '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 facultatif SAUT DE DÉPENDANCE FACULTATIVE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\process-nextick-args) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez '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 facultatif SAUT DE DÉPENDANCE FACULTATIVE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\safe-buffer) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez '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 facultatif SAUT DE DÉPENDANCE FACULTATIVE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\safer-buffer) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez '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 facultatif SAUT DE DÉPENDANCE OPTIONNELLE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\sax) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\sax' -> 'C:\ Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.sax.DELETE'
npm WARN facultatif SAUT DE DÉPENDANCE OPTIONNELLE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\semver) :
npm WARN enoent Ignorer la dépendance facultative : ENOENT : aucun fichier ou répertoire de ce type, renommez 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\semver' -> 'C:\ Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.semver.DELETE'
npm WARN facultatif SAUT DE DÉPENDANCE FACULTATIVE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\set-blocking) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\set-blocking' -> 'C :\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.set-blocking.DELETE'
npm WARN facultatif SAUT DE DÉPENDANCE OPTIONNELLE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\signal-exit) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez '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 facultatif SAUT DE DÉPENDANCE OPTIONNELLE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\strip-json-comments) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez '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 facultatif SAUT DE DÉPENDANCE FACULTATIVE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\util-deprecate) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez '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 facultatif SAUT DE DÉPENDANCE FACULTATIVE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\wrappy) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\wrappy' -> 'C:\ Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.wrappy.DELETE'
npm WARN facultatif SAUT DE DÉPENDANCE FACULTATIVE : [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\yallist) :
npm WARN enoent SAUT DE DÉPENDANCE OPTIONNELLE : ENOENT : aucun fichier ou répertoire de ce type, renommez 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\yallist' -> 'C:\ Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.yallist.DELETE'

npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142
pourriez-vous m'aider s'il vous plait? Je ne peux pas résoudre ce problème et je ne peux pas démarrer mon projet

npm WARN deprecated [email protected] : la requête a été dépréciée, voir #3142
pourriez-vous m'aider s'il vous plait? Je ne peux pas résoudre ce problème et je ne peux pas démarrer mon projet

Moi non plus

@liaz98 @TheLitz ce n'est pas une erreur, c'est un avertissement. Si votre projet ne sera pas généré/démarré en raison d'un avertissement npm, alors quelque chose ne va pas avec votre projet et/ou votre environnement. Ce n'est pas un problème avec la demande.

@liaz98 @TheLitz ce n'est pas une erreur, c'est un avertissement. Si votre projet ne sera pas généré/démarré en raison d'un avertissement npm, alors quelque chose ne va pas avec votre projet et/ou votre environnement. Ce n'est pas un problème avec la demande.

mais quand j'essaye d'animer l'Expo, ça ne marche pas

@TheLitz alors c'est un problème avec Expo, et vous devriez le signaler dans leur bug tracker. Rien ne peut ou ne sera résolu du côté de la demande.

@TheLitz alors c'est un problème avec Expo, et vous devriez le signaler dans leur bug tracker. Rien ne peut ou ne sera résolu du côté de la demande.

D'accord. Merci

nous demandons une future demande.

tldr;
qu'est-ce que je suis censé utiliser maintenant ?

@YashKumarVerma https://github.com/request/request/issues/3143

@YashKumarVerma utilise postman-request

@TheLitz alors c'est un problème avec Expo, et vous devriez le signaler dans leur bug tracker. Rien ne peut ou ne sera résolu du côté de la demande.

est-ce que tu résous ce problème ????
npm WARN deprecated [email protected] : la requête a été dépréciée,

Alors, quel est le guide sur la manière alternative de faire une demande https pour moi qui est nouveau pour le développement back-end avec node ?

@OluwafemiAdesegha
Avez-vous réussi à obtenir des éclaircissements sur l'endroit où vous déplacer ? Je suis dans le même bateau que vous! :(

Pour tous ceux qui recherchent des alternatives, regardez #3143 ( @farhan3040 @OluwafemiAdesegha @iamdesfranco )

@mikeal, je recommanderais de fermer ce problème ;)

@iamdesfranco @farhan3040 HTTP était obsolète, veuillez utiliser Gopher ou UDP

@mikeal, je recommanderais de fermer ce problème ;)

Ou plutôt le verrouiller. Essentiellement, tout ce qui doit être dit a été dit à ce stade, et les seules questions posées ont tendance à être celles auxquelles on a déjà répondu (plusieurs fois).

Franco,

Excuses pour la réponse tardive. J'essaye toujours de voir ce que je ferais
enfin aller avec en fonction des suggestions données.

Le Lun 6 Avr 2020 09:12 Franco Labuschagne [email protected]
a écrit:

Alors, quel est le guide sur la façon alternative de faire une demande https pour moi
c'est nouveau pour le développement back-end avec node ?

Avez-vous réussi à obtenir des éclaircissements sur l'endroit où vous déplacer ? je suis dans le même bateau
comme toi! :(

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/request/request/issues/3142#issuecomment-609643295 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AOL4QYXM7V2BUK5LZCS7LDDRLGFH5ANCNFSM4HCP6LRA
.

et les alternatives possibles se réfèrent à cette question.

Où ai-je trouvé les alternatives sur cette page ?

Est-ce que la suggestion d'utiliser fetch dans le navigateur + fetch lib pour le nœud, ou simplement une alternative basée sur une promesse, etc.?

@TomYeoman La suggestion est de ne pas utiliser request .

@gcacars Alternatives ici : https://github.com/request/request/issues/3143

@Richienb merci. Je pense qu'il est important d'avoir un lien vers cela dans le README.

J'ai supprimé le dossier "node_modules" et le fichier "package-lock.json", puis j'ai exécuté les 2 commandes suivantes.
npm init
npm installer

Et puis, ça a bien fonctionné.

Les commiters qui sont encore actifs essaieront de fusionner les correctifs en temps opportun, sans promesse cependant.

Jeu de mots accidentel brillant (?)

npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142

comment résoudre ça ???,

@anton-bot Pas de malware s'il vous plaît.

npm WARN deprecated [email protected] : la requête a été dépréciée, voir #3142

comment résoudre ça ???,

@Amouthinie il n'y a rien à résoudre, ce n'est pas une erreur. NPM vous avertit que request est obsolète et que vous (ou quiconque gère vos dépendances qui dépendent à leur tour de request ) devriez plutôt envisager de passer à un package activement maintenu.

J'ai eu deux problèmes :
1 - sudo apt-get install nodejs npm
Lecture des listes de paquets... Terminé
Arbre de dépendance de construction
Lecture des informations d'état... Terminé
nodejs est déjà la version la plus récente (13.13.0-1nodesource1).
Certains packages n'ont pas pu être installés. Cela pourrait signifier que
vous avez demandé une situation impossible ou, si vous utilisez le
distribution instable, que certains packages requis n'étaient pas
créé pour le moment ou supprimé de "Incoming".
Les informations suivantes peuvent aider à résoudre la situation :

Les packages suivants ont des dépendances incompatibles :
nodejs : Conflit : npm
E : Impossible de résoudre les problèmes, vous avez conservé (en attente) les packages cassés.

2 - sudo npm install -g @angular/cli
npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142
npm ERR ! Code EEXIST
npm ERR ! lien symbolique d'appel système
npm ERR ! chemin ../lib/node_modules/@angular/cli/bin/ng
npm ERR ! dest /usr/bin/ng
npm ERR ! errno -17
npm ERR ! EEXIST : le fichier existe déjà, lien symbolique '../lib/node_modules/@angular/cli/bin/ng' -> '/usr/bin/ng'
npm ERR ! Le fichier existe : /usr/bin/ng
npm ERR ! Supprimez le fichier existant et réessayez, ou exécutez npm
npm ERR ! avec --force pour écraser les fichiers imprudemment.

npm ERR ! Un journal complet de cette course peut être trouvé dans:
npm ERR ! /home/anderson/.npm/_logs/2020-04-17T16_25_56_704Z-debug.log

Je suis un utilisateur de Linux Mint 19.3 Cinnamon, 4.4.8, 5.3.0-46-generic

Quelqu'un peut-il m'aider?

@LeloCorrea Votre erreur n'est pas liée à request , c'est un problème avec la création d'un lien symbolique dans votre environnement local :

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

@LeloCorrea Votre erreur n'est pas liée à request , c'est un problème de création d'un lien symbolique dans votre environnement local :

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

Savez-vous comment je peux résoudre ce problème ?

@LeloCorrea Votre erreur n'est pas liée à request , c'est un problème de création d'un lien symbolique dans votre environnement local :
npm ERR! EEXIST: file already exists, symlink '../lib/node_modules/@angular/cli/bin/ng' -> '/usr/bin/ng'

Savez-vous comment je peux résoudre ce problème ?

Ce n'est pas exactement le même problème, mais la solution peut être la même. Vous devriez commencer ici :

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

De plus, encore une fois, ce problème n'est en aucun cas lié à la demande , vous devez demander de l'aide sur la CLI angulaire dans le suivi des problèmes correspondant.

Alors, quelle est l'alternative recommandée? Utiliser uniquement les packages http/https ?

@RonRofe J'utilise https://github.com/sindresorhus/got , semble être un bon successeur, il a un guide sur la façon de migrer à partir d'une demande .

@RonRofe, il existe une liste (WIP) d'alternatives ici : https://github.com/request/request/issues/3143

Je suis triste de ce départ, la demande a été ma bibliothèque préférée depuis aussi longtemps que je me souvienne.
Je ne peux que remercier l'auteur et les contributeurs pour le travail incroyable qu'ils ont fourni au fil des ans, et j'espère que votre prochaine aventure sera aussi excitante que celle-ci.
À votre santé!

pouvez-vous donner des recommandations d'alternatives dans votre premier commentaire collant ?

Bonjour, j'essaye de créer un nouveau projet angulaire et j'ai cette erreur :
/ Installation des packages...npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142
npm WARN obsolète [email protected] : Chokidar 2 se brisera sur le nœud v14+. Passez à chokidar 3 avec 15 fois moins de dépendances.
npm WARN obsolète [email protected] : fsevents 1 s'arrêtera sur le nœud v14+. Passez à fsevents 2 avec des améliorations massives.
npm WARN obsolète [email protected] : veuillez consulter https://github.com/lydell/urix#deprecated
npm WARN déconseillé [email protected] : https://github.com/lydell/resolve-url#deprecated
npm ERR ! Fin inattendue de l'entrée JSON lors de l'analyse près de '...":{"@angular/core":"5'

npm ERR ! Un journal complet de cette course peut être trouvé dans:
npm ERR ! C:\Users\dell\AppData\Roamingnpm-cache_logs\2020-04-21T11_50_16_582Z-debug.log
× L'installation du package a échoué, voir ci-dessus.
Le workflow schématique a échoué. Voir au dessus.
Quelqu'un pourrait-il m'aider avec cela?

Bonjour, j'essaye de créer un nouveau projet angulaire et j'ai cette erreur :
/ Installation des packages...npm WARN deprecated [email protected] : la requête a été dépréciée, voir #3142
npm WARN obsolète [email protected] : Chokidar 2 se brisera sur le nœud v14+. Passez à chokidar 3 avec 15 fois moins de dépendances.
npm WARN obsolète [email protected] : fsevents 1 s'arrêtera sur le nœud v14+. Passez à fsevents 2 avec des améliorations massives.
npm WARN obsolète [email protected] : veuillez consulter https://github.com/lydell/urix#deprecated
npm WARN déconseillé [email protected] : https://github.com/lydell/resolve-url#deprecated
npm ERR ! Fin inattendue de l'entrée JSON lors de l'analyse près de '...":{"@angular/core":"5'

npm ERR ! Un journal complet de cette course peut être trouvé dans:
npm ERR ! C:\Users\dell\AppData\Roamingnpm-cache_logs\2020-04-21T11_50_16_582Z-debug.log
× L'installation du package a échoué, voir ci-dessus.
Le workflow schématique a échoué. Voir au dessus.
Quelqu'un pourrait-il m'aider avec cela?

Moi aussi

CRÉER mon-projet/angular.json (3598 octets)
CRÉER mon-projet/package.json (1286 octets)
CRÉER mon-projet/README.md (1026 octets)
CRÉER mon-projet/tsconfig.json (489 octets)
CRÉER mon-projet/tslint.json (3125 octets)
CRÉER mon-projet/.editorconfig (274 octets)
CRÉER mon-projet/.gitignore (631 octets)
CRÉER mon-projet/liste de navigateurs (429 octets)
CRÉER mon-projet/karma.conf.js (1022 octets)
CRÉER mon-projet/tsconfig.app.json (210 octets)
CRÉER mon-projet/tsconfig.spec.json (270 octets)
CRÉER mon-projet/src/favicon.ico (948 octets)
CRÉER mon-projet/src/index.html (295 octets)
CRÉER mon-projet/src/main.ts (372 octets)
CRÉER mon-projet/src/polyfills.ts (2835 octets)
CRÉER mon-projet/src/styles.css (80 octets)
CRÉER mon-projet/src/test.ts (753 octets)
CRÉER mon-projet/src/assets/.gitkeep (0 octets)
CRÉER mon-projet/src/environments/environment.prod.ts (51 octets)
CRÉER mon-projet/src/environments/environment.ts (662 octets)
CRÉER mon-projet/src/app/app-routing.module.ts (246 octets)
CRÉER mon-projet/src/app/app.module.ts (393 octets)
CRÉER mon-projet/src/app/app.component.html (25757 octets)
CRÉER mon-projet/src/app/app.component.spec.ts (1071 octets)
CRÉER mon-projet/src/app/app.component.ts (214 octets)
CRÉER mon-projet/src/app/app.component.css (0 octets)
CRÉER mon-projet/e2e/protractor.conf.js (808 octets)
CRÉER mon-projet/e2e/tsconfig.json (214 octets)
CRÉER mon-projet/e2e/src/app.e2e-spec.ts (643 octets)
CRÉER mon-projet/e2e/src/app.po.ts (301 octets)
/ Installation des packages...npm WARN obsolète [email protected] : TSLint a été obsolète au profit d'ESLint. Veuillez consulter https://github.com/palantir/tslint/issues/4534 pour plus d'informations.
npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142
npm WARN obsolète [email protected] : mise à niveau vers chokidar 3 avec 15 fois moins de dépendances. Chokidar 2 se brisera sur le nœud v14.
npm WARN obsolète [email protected] : veuillez consulter https://github.com/lydell/urix#deprecated
npm WARN déconseillé [email protected] : https://github.com/lydell/resolve-url#deprecated
npm ERR ! Fin inattendue de l'entrée JSON lors de l'analyse près de '....0.1","systemjs":"^0.'

npm ERR ! Un journal complet de cette course peut être trouvé dans:
npm ERR ! C:\Users\92306\AppData\Roamingnpm-cache_logs\2020-04-21T16_08_05_350Z-debug.log
× L'installation du package a échoué, voir ci-dessus.
Le workflow schématique a échoué. Voir au dessus.

@awais0048 @xunyegege votre erreur n'a rien à voir avec la demande. Étudiez la sortie réelle et elle vous indique précisément quelle est l'erreur. Si vous rencontrez d'autres problèmes avec Angular CLI, signalez-le dans leur outil de suivi des problèmes.

@awais0048 @xunyegege votre erreur n'a rien à voir avec la demande. Étudiez la sortie réelle et elle vous indique précisément quelle est l'erreur. Si vous rencontrez d'autres problèmes avec Angular CLI, signalez-le dans leur outil de suivi des problèmes.

J'ai essayé de mettre à niveau NPM et node mais aucune idée. si quelqu'un trouve une solution pouvez vous me le dire s'il vous plait ?

@ANadjia encore

Salut, Installation de packages... npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142 npm ERR ! Fin inattendue de l'entrée JSON lors de l'analyse près de '...ZXQ4dst\n4bcYaiOdlbvh'
quand je crée un nouveau projet
Aucune suggestion

Il y a deux mois...

https://github.com/request/request/issues/3142#issuecomment -585561589

@mohamedelsoufi c'est un problème avec votre environnement ou projet, pas ce package. NPM vous avertit uniquement que ce package est obsolète.

@milette
Bonne idée de garder ce fil en cours d'exécution pour rappeler les conséquences de la dépréciation d'un package utilisé dans 99% des projets dans le monde.

@anton-bot En fait, un rappel du nombre de personnes qui ne RTFM pas.

@csvan et ils disent que ce n'est pas non plus leur problème
Quoi qu'il en soit, j'ai enfin réussi à faire fonctionner les choses pour moi.
Donc en gros :
1/je rétrograder vers node js version 10.13.0 ;
2/ j'ai supprimé manuellement le dossier npm_cache
3/ lancer npm install ;
et par magie ça a marché

@ANadjia c'est bon à entendre !

Le remplacement suggéré n'est pas clair. Que devrions-nous utiliser à la place ?

@johnworthley tout ce qui fonctionne pour vous. Il y a une liste d'alternatives suggérées ici : https://github.com/request/request/issues/3143

@johnworthley tout ce qui fonctionne pour vous. Il y a une liste d'alternatives suggérées ici : #3143

hmm bel endroit https://www.youtube.com/watch?v=riuZHZPcZsg

Pouvons-nous toujours utiliser cette bibliothèque même si elle est obsolète ? Veuillez aviser @mikeal

Pouvons-nous toujours utiliser cette bibliothèque même si elle est obsolète ? s'il vous plaît donnez votre avis

@DokurOmkar Oui. Rien ne vous empêche d'utiliser la bibliothèque. C'est simplement un avertissement. Cependant, il est obsolète pour une raison : il existe des bibliothèques meilleures et plus modernes. Lisez ce fil et vous trouverez un lien vers une liste de bibliothèques alternatives.

impossible de créer un nouveau projet angulaire
il échoue en raison de -
npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142

@adibhosale Vous avez plus d'informations ? Quels sont les autres messages dans la console que vous voyez ?

@adibhosale non, ça

@anton-bot
Répondre à - > @adibhosale Avez-vous plus d'informations ? Quels sont les autres messages dans la console que vous voyez ?

C'est l'erreur que je reçois lors de la création d'un nouveau projet angulaire.

Installation des packages...npm WARN obsolète [email protected] : TSLint a été obsolète au profit d'ESLint. Veuillez consulter https://github.com/palantir/tslint/issues/4534 pour plus d'informations.
npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142
npm WARN obsolète [email protected] : Chokidar 2 se brisera sur le nœud v14+. Passez à chokidar 3 avec 15 fois moins de dépendances.
npm WARN obsolète [email protected] : fsevents 1 se brisera sur le nœud v14+ et pourrait utiliser des binaires non sécurisés. Mise à niveau vers fsevents 2.
npm WARN obsolète [email protected] : veuillez consulter https://github.com/lydell/urix#deprecated
npm WARN déconseillé [email protected] : https://github.com/lydell/resolve-url#deprecated
npm ERR ! cb() n'a jamais appelé !

npm ERR ! Veuillez signaler cette erreur à l'adresse :
npm ERR ! https://npm.community

npm ERR ! Un journal complet de cette course peut être trouvé dans:
npm ERR ! C:\Users\adibh\AppData\Roamingnpm-cache_logs\2020-05-05T08_46_31_829Z-debug.log
× L'installation du package a échoué, voir ci-dessus.
Le workflow schématique a échoué. Voir au dessus.

Je ne comprends pas pourquoi tant d'utilisateurs signalent des détails totalement non pertinents à ce problème ?

Il semble que la plupart des utilisateurs qui sont venus ici n'aient aucune idée de ce qu'ils font, ne comprennent probablement même pas ce que signifie le mot déprécié.

mais le dernier message posté ici, il y a plus d'un message d'obsolescence, pourquoi choisissent-ils de signaler ce problème ? parce que certains utilisateurs l'ont déjà fait et qu'ils continuent ?

et le dernier bit de ce message spécifique, indique spécifiquement que le bogue npm doit être signalé à npm.community.

les responsables ici, je pense, devraient supprimer tous les éléments de discussion non pertinents pour demander la dépréciation et verrouiller les discussions ici.

peut-être que le message d'obsolescence du package de requêtes devrait être remplacé par un lien, plutôt un problème, comme le font les packages lydell/urix et lydell/resolve-url, de sorte que le flot de messages non pertinents n'apparaît pas ici.

@glensc Qui savait que la dépréciation d'un package utilisé par presque tous les projets JS dans le monde aurait des conséquences imprévues !

@glensc nous

Merci :-)

S'il indique WARN, cela signifie que ce n'est pas un ERR. Juste quelques faits.

@adibhosale non, vous recevez un avertissement NPM qui a un lien vers ce problème github - parmi BEAUCOUP d'autres liens dans la même sortie de journal. L'avertissement n'a rien à voir avec l'échec, vous devez lire le journal plus attentivement. Il indique clairement 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

et c'est la raison pour laquelle l'installation échoue. Vous devez faire preuve de diligence raisonnable et déterminer les causes de cela avant de signaler un problème dans un package qui n'a absolument rien à voir avec cela.

@anton-bot tu n'arrêtes pas de le dire. Avez-vous quelque chose de constructif à contribuer ou êtes-vous toujours là pour troller ?

@csvan @leoskyrocker @glensc Je m'excuse d'avoir initié cela. Sera prendre soin à l'avenir. Merci :-)

comment résoudre ce problème
impossible de créer un projet angulaire
problème

////////

obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142
npm WARN checkPermissions Accès en écriture manquant à /usr/local/lib/node_modules
npm ERR ! code EACCES
npm ERR ! accès aux appels système
npm ERR ! chemin /usr/local/lib/node_modules
npm ERR ! errno -13
npm ERR ! Erreur : EACCES : autorisation refusée, accès '/usr/local/lib/node_modules'
npm ERR ! [Erreur : EACCES : autorisation refusée, accès '/usr/local/lib/node_modules'] {
npm ERR ! numéro d'erreur : -13,
npm ERR ! code : 'EACCES',
npm ERR ! syscall : 'accès',
npm ERR ! chemin : '/usr/local/lib/node_modules'
npm ERR ! }
npm ERR !
npm ERR ! L'opération a été rejetée par votre système d'exploitation.
npm ERR ! Il est probable que vous n'ayez pas les autorisations pour accéder à ce fichier en tant qu'utilisateur actuel
npm ERR !
npm ERR ! Si vous pensez qu'il s'agit d'un problème d'autorisation, veuillez vérifier
npm ERR ! autorisations du fichier et de ses répertoires contenant, ou essayez d'exécuter
npm ERR ! la commande à nouveau en tant que root/administrateur.

npm ERR ! Un journal complet de cette course peut être trouvé dans:
npm ERR ! /Users/vivek/.npm/_logs/2020-05-05T11_48_34_569Z-debug.log

@ vivek08011991 la sortie du journal explique ce que vous devez faire. Il s'agit d'un problème lorsque vous essayez d'installer angular globalement sans utiliser sudo . Cela n'a rien à voir avec ce paquet.

Hé mec, c'est une merde de parler, peu importe,
je vais vous dire la solution
j'ai essayé 3 jours puis je l'ai eu
premier: npm installer npm
seconde: npm uninstall --save react-native-cli
enfin : npm install -g @angular/cli

Hé mec, c'est une merde de parler, peu importe,
je vais vous dire la solution
j'ai essayé 3 jours puis je l'ai eu
premier: npm installer npm
seconde: npm uninstall --save react-native-cli
enfin : npm install -g @angular/cli

Mec tu avais raison alhamdou lil allah. Pourquoi réagir cli est à l'origine du problème ? y a-t-il des pratiques de concurrence laides là-bas ? Merci mon pote

s'il vous plaît faites attention à ceci est request tracker de problème de module, pas angular .

• https://lmgtfy.com/?q=angular+cli

Quelqu'un peut-il me dire l'alternative à request ?

Je lis ceci et je préfère request loin l'API simpliste de

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

@dolanmiu Bien sûr. Quiconque a lu le fil sur lequel vous venez de publier (ou même l'a recherché _alternative_) pourrait vous dire qu'il existe une liste d'alternatives sur https://github.com/request/request/issues/3143.

@dolanmiu @root/request est un remplacement principalement

@Richienb entre postman-request (également un remplacement

@anton-bot Certainement @root/request.

J'utilise request depuis un certain temps maintenant et je suis d'accord avec mikeal. Les modules natifs de Node ont été développés au fil du temps pour correspondre à ce module request qu'il n'y a plus aucune raison de l'utiliser, autre que de corriger à plusieurs reprises le code lorsqu'une nouvelle version de request est arrivée dehors.

request sera inscrit à jamais dans les pierres de l'histoire ; node a grandi. C'est à peu près le moment où nous devons laisser aller certaines choses. request a toujours été un pionnier des fonctionnalités innovantes, et je pense que sans request , le développement de nœuds n'aurait pas été aussi génial.

En tant que jeune programmeur, j'ai adoré utiliser ce package, mais je sais aussi que pour améliorer et construire des programmes encore plus performants, il ne faut plus s'attarder sur le passé.

En tant que jeune programmeur, j'ai adoré utiliser ce package

Ça m'a fait rire. En tant que jeune programmeur, j'utilisais Commodore BASIC. :souriant:

@darkRaspberry :

1. lisez votre rapport d'erreur jusqu'à la fin, pas seulement la première ligne, il y a clairement écrit quelle est l'erreur et même une suggestion quoi faire. vous n'avez clairement pas lu au-delà de la première ligne.
2. as-tu googlé ton erreur ?
3. lisez les discussions précédentes et expliquez pourquoi vous postez ceci ici, votre rapport de problème n'a rien à voir avec le module de requêtes.

désactivez simplement votre antivirus, vous n'aurez aucune erreur
Merci !!!

@glensc j'ai complètement réinstallé mon terminal pour supprimer toute autre version de node puis j'ai essayé "sudo"
Et ça a marché.
J'utilise la version node de nodejs en utilisant curl pour ajouter node js dans mon PPA.

et ici ça a marché
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

Cela m'a rendu émotif. Et :bow: à tous les contributeurs !

@sudarsan2017 Cette erreur n'est en aucun cas liée à request

Salut! les gars rencontrent le même problème sous Windows et je l'ai résolu en utilisant la commande

npm installer [email protected]

J'espère que le vôtre a raison.

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

Comment je le répare ?

@aman78600 Il n'y a aucun moyen de le réparer.

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

@aman78600 Il n'a pas besoin d'être réparé. C'est juste un avertissement que request has been deprecated .

Votre MNP dit de venir ici pour des alternatives, mais je ne les vois pas.

Votre MNP dit de venir ici pour des alternatives, mais je ne les vois pas.

@skeddles Si vous aviez appuyé sur Ctrl-F et recherché alternatives , vous auriez trouvé le lien vers https://github.com/request/request/issues/3143.

Je ne peux pas installer vue-cli à partir de cette commande npm install -g @vue/cli son affiche le message : npm WARN deprecated [email protected] : la demande a été dépréciée

@somnangrom Cela ne peut pas être vrai, je suis sûr qu'il y a d'autres messages dans la console et pas seulement cette ligne.

Je voulais vraiment vous remercier d'avoir travaillé sur ce package. Cela m'a beaucoup aidé dans mes projets. Raisons tout à fait compréhensibles pour lesquelles le support est arrêté.

Vous avez fait un travail formidable, vous devriez être fiers de vous !

??

Je ne parviens pas à installer la dernière version d'Angular CLI.
Nodejs version 64 bits : 12.18.1
version npm : 6.13.6
Lorsque j'exécute npm install -g @angular/ cli@latest pour installer la dernière version d'Angular CLI, cela me donne l'avertissement d'erreur suivant
npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142

L'installation se bloque avec le message : postinstall : sill install executeActions
Merci de m'aider à résoudre ce problème

Je ne parviens pas à installer la dernière version d'Angular CLI.
J'ai installé Nodejs sur mon ordinateur portable Windows 10 Pro
Version Nodejs 64 bits : 12.18.1version npm : 6.13.6
Lorsque j'exécute npm install -g @angular/ cli@latest pour installer la dernière version d'Angular CLI, cela me donne l'avertissement d'erreur suivant
npm WARN deprecated [email protected] : la requête a été dépréciée, voir #3142

L'installation se bloque avec le message : postinstall : sill install executeActions
Merci de m'aider à résoudre ce problème

@anjaikr et @aman78600 se réfèrent à https://github.com/angular/angular-cli/wiki/stories-1.0-update pour installer la dernière version en espérant que cela aide

npm install -g json-server ne fonctionne pas, que dois-je faire ?

On peut toujours l'utiliser pour des actions basiques, non ?

j'obtiens une erreur lors de l'installation d'angular 5, j'ai essayé d'installer mais cela montre que la demande a été obsolète... que dois-je faire

@mikeal Pour être clair, avez-vous l'intention de remplacer request bent par request ?

Bonjour,

Quelqu'un sait quel est le problème :
npm i -g json-server
npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142
npm WARN obsolète [email protected] : cette bibliothèque n'est plus prise en charge

THX.

L'une des raisons les plus stupides que j'ai entendues pour la dépréciation. Imaginez si Google et Microsoft retiraient tous leurs produits des étagères parce qu'il est "beaucoup plus difficile pour les nouvelles bibliothèques accomplissant des tâches similaires d'être adoptés" et parce qu'"il y a actuellement une transition dans l'écosystème vers ces modèles". Complètement ridicule.

Tout d'abord, montrez mon respect pour ce dépôt, cependant, pour être honnête, ce que @cypheron a dit avait du sens.

@Wenjie-Shao Aucun sens, j'en ai peur. Sans l'avis d'obsolescence, encore plus de personnes téléchargeraient et utiliseraient cette bibliothèque sans se rendre compte qu'elle est obsolète. @mikeal a rendu un grand service à la communauté en désapprouvant formellement cette bibliothèque plutôt que de simplement la laisser pourrir. Peut-être que l'erreur était de créer un lien vers ce fil.

J'essaie juste de me frayer un chemin dans le didacticiel pour configurer surge.sh.

On dirait que vous avez beaucoup de choses à faire ici. Est-ce que ça va me bousiller ici dans le nouveau futur si j'ignore juste les avertissements et pars ?

L'une des raisons les plus stupides que j'ai entendues pour la dépréciation. Imaginez si Google et Microsoft retiraient tous leurs produits des étagères parce qu'il est "beaucoup plus difficile pour les nouvelles bibliothèques accomplissant des tâches similaires d'être adoptés" et parce qu'"il y a actuellement une transition dans l'écosystème vers ces modèles". Complètement ridicule.

Mais ils l'ont fait. Et souvent. Il existe de très nombreux produits de ces géants du logiciel qui n'existent plus ou sont actuellement obsolètes et ne reçoivent aucune mise à jour. Avez-vous déjà entendu parler, disons, de Windows 95 ou de FoxPro ? Chaque projet logiciel finira par se terminer pour une raison ou une autre. Et les auteurs de Request ne le retirent pas non plus des étagères, ils arrêtent les nouveaux développements. Des corrections de bogues critiques se produiront encore pendant un certain temps et si votre projet en dépend, aucun problème. Vous pouvez toujours continuer à l'utiliser.

Mais si vous démarrez un nouveau projet, il existe des alternatives meilleures et plus modernes. Le langage a évolué, il existe de meilleures façons de faire les mêmes choses maintenant, mais Request ne peut pas le suivre car il a besoin des projets hérités pour fonctionner avec. Pour les nouveaux projets, c'est sous-optimal.

Cette décision me semble donc tout à fait logique. Laissez Request là où il se trouve pour que les projets hérités puissent continuer à l'utiliser, mais pour les nouveaux projets, recommandez de nouvelles bibliothèques.

Y a-t-il une raison spécifique pour laquelle quelqu'un utiliserait la requête sur axios ?

Y a-t-il une raison spécifique pour laquelle quelqu'un utiliserait la requête sur axios ?

Sûr. Du haut de ma tête:

• Vous y êtes juste habitué ou avez beaucoup d'expérience avec
• Votre projet l'utilise déjà partout. Tout changer prendrait des semaines, voire des mois, de réécriture de code.
• Les directives de codage de l'entreprise/du projet exigent cette bibliothèque (ou n'autorisent que les bibliothèques avec certaines exigences de "maturité")
• Une bibliothèque tierce l'exige (et peut-être même exige que vous l'utilisiez lorsque vous travaillez avec la bibliothèque). Points supplémentaires si la bibliothèque n'a pas d'alternative.
• Vous êtes un étudiant et le cours que vous suivez enseigne explicitement la demande et l'a dans les examens/les devoirs

En substance, ce sont toutes des variantes du même thème - vous devez travailler avec des éléments hérités qui n'ont pas encore rattrapé les dernières tendances. Cela a tendance à se produire assez régulièrement dans la vraie vie.

npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142
npm WARN obsolète @hapi/ [email protected] : joi quitte l'organisation @hapi et revient à 'joi' (https://github.com/sideway/joi/issues/2411)
npm WARN obsolète @hapi/ [email protected] : cette version a été obsolète et n'est plus prise en charge ni maintenue
NPM WARN désapprouvée @ Hapi / [email protected] : Cette version est obsolète et n'est pris en charge ou maintenu plus
npm WARN obsolète @hapi/ [email protected] : cette version a été obsolète et n'est plus prise en charge ni maintenue
npm WARN obsolète @hapi/ [email protected] : cette version a été obsolète et n'est plus prise en charge ni maintenue
npm WARN obsolète [email protected] : cette bibliothèque n'est plus prise en charge
npm WARN obsolète [email protected] : veuillez consulter https://github.com/lydell/urix#deprecated
npm WARN déconseillé [email protected] : https://github.com/lydell/resolve-url#deprecated
npm WARN obsolète [email protected] : Chokidar 2 se brisera sur le nœud v14+. Passez à chokidar 3 avec 15 fois moins de dépendances.
npm WARN obsolète [email protected] : fsevents 1 se brisera sur le nœud v14+ et pourrait utiliser des binaires non sécurisés. Mise à niveau vers fsevents 2.

POURQUOI ???? TOUTES MES INSTALLATIONS GLOBALES NPM M'AVERTISSENT TOUJOURS QU'ELLE EST DÉCONSEILLÉE ?? COMMENT RÉGLER CECI

J'ESSAYE DE DÉSINSTALLER NODEJS
OU
MISE À JOUR NPM
MAIS ÇA NE FONCTIONNE PAS
AIDEZ-MOI, S'IL VOUS PLAÎT

IL EST DÉCONSEILLÉ.
VOUS NE POUVEZ PAS RÉPARER CELA.
IGNOREZ L'AVERTISSEMENT.

_{Ou réécrivez votre code pour qu'il n'utilise pas Request.}

@acatzk

Essayer

npm install -s (ou --silent)
ou

npm install -q (ou --quiet)

faire taire les avertissements

Ce fil est le meilleur.

Salut. Je suis nouveau sur les API. J'essayais d'installer le package de demande et il a dit qu'il est maintenant obsolète. J'ai essayé de chercher et de voir ce qui se passe, mais j'apprécierais que quelqu'un puisse m'expliquer ce que je peux faire maintenant ? Cela signifie-t-il que le package de demande n'est plus utilisable ? Quel autre package puis-je utiliser pour faire le même travail ?

@ mohammed3736 Non, il peut toujours être utilisé. Mais il ne sera pas mis à jour. Il n'obtiendra pas de nouvelles fonctionnalités. Il peut y avoir quelques corrections de bugs pendant un petit moment, mais pas pour longtemps. Et l'avertissement sera toujours là. Essentiellement, ils abandonnent le projet. Si vous souhaitez y apporter des modifications, vous devrez le faire vous-même. Après tout, tout le code source de la demande est toujours disponible. Vous pouvez faire votre propre fourchette et faire n'importe quoi avec.

Si vous écrivez un nouveau projet, essayez une autre bibliothèque plus moderne. Par exemple, nous utilisons Axios, mais je suis sûr qu'il y en a d'autres.

Je vais poser la question suivante sur mes interviews maintenant au lieu 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 C'est simple, la réponse est : "Je clique sur le lien, ne lis rien mais va au bas du fil et poste la même question que tout le monde."

Est-ce que j'obtiens le travail ?

@anton-bot C'est simple, la réponse est : "Je clique sur le lien, ne lis rien mais va au bas du fil et poste la même question que tout le monde."

Est-ce que j'obtiens le travail ?

La raison pour laquelle je posais la question est que j'obtiens toujours des 401 sur le journal de ma console. Et le module de demande ne fonctionne pas pour moi. J'essaie d'utiliser l'api de bitcoinaverage et de https://any-api.com/ et aucun d'entre eux ne fonctionnait. Lorsque je vais dans localhost3000, le code HTML fonctionne et j'obtiens la page, mais lorsque j'appuie sur le bouton pour obtenir le résultat, ma console se bloque. Le journal de ma console indique que l'application s'est écrasée ou 401 pour le statusCode et sur le navigateur. Notez également qu'aucun de mes proxys n'est activé, j'ai tout essayé mais j'obtiens toujours des erreurs. SI vous pouvez m'aider je vous en serais reconnaissant.

@ mohammed3736 - Ce n'est pas le bon endroit pour demander. De plus, je suis sûr à 99,99% que ce n'est pas la bibliothèque de requêtes qui est à blâmer. Il y a un bogue dans votre programme et vous l'avez fait vous-même. Vous devrez également le découvrir vous-même. Si vous avez toujours besoin d'aide, essayez de demander à StackOverflow, mais veuillez inclure le code qui ne fonctionne pas. Mieux encore, essayez de créer le plus petit programme possible qui plante et affichez ce code source.

Je suis aussi venu ici pour poser une question mais... qu'est-ce qui se passe avec toutes les attaques racistes ici ? vous êtes incroyables.

Et oui, je ne sais toujours pas pourquoi mon code ne fonctionne pas. La seule erreur dans la console m'amène ici.

Vérifiez votre privilège et amusez-vous

Je suis aussi venu ici pour poser une question mais... qu'est-ce qui se passe avec toutes les attaques racistes ici ? vous êtes incroyables.

Et oui, je ne sais toujours pas pourquoi mon code ne fonctionne pas. La seule erreur dans la console m'amène ici.

Vérifiez votre privilège et amusez-vous

De quelles attaques racistes parlez-vous ? Cela sonne vraiment mal

Même problème observé. S'il vous plaît aider si quelqu'un sait comment résoudre

[email protected] : la requête a été dépréciée, voir https://github.com/request/request/issues/3142

@ HaseebAhmed49, le package npm "request" étant déprécié n'est pas un problème en soi. le message s'adresse aux développeurs de projets de bibliothèque.

Ne t'en fais pas. Beaucoup de gens sur github m'ont dit que ça allait. Ce
signifie simplement que le package n'aura pas de nouvelles fonctionnalités ajoutées
à lui plus et il ne sera pas mis à jour mais il est toujours parfaitement bien de
utilisation. Je l'ai utilisé et c'était bien.

Le lun. 14 sept. 2020 à 23:57 Elan Ruusamäe [email protected]
a écrit:

>
>

@HaseebAhmed49 https://github.com/HaseebAhmed49 la "demande" npm
le paquet étant déprécié n'est pas un problème en soi. le message est à la bibliothèque
développeurs de projets.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/request/request/issues/3142#issuecomment-692279572 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AQFTBJ255VRYJW4VMUFQQ23SFZYSZANCNFSM4HCP6LRA
.

mais il est toujours parfaitement bien à utiliser

Pas vraiment. Cela peut fonctionner _pour l'instant_, mais vous ne devriez jamais avoir de dépendance explicite sur un paquet qui ne recevra pas d'autres correctifs de bogues et de sécurité. Vous exposez votre application (et les utilisateurs) à un risque important de rupture soudaine et de fuites de sécurité lorsque ce package finit par _cesser_ de fonctionner (ce qu'il fera presque certainement). Cela est particulièrement vrai pour un package comme request qui fournit quelque chose d'aussi crucial et sensible que de faire des requêtes réseau.

Un avertissement de dépréciation est un avis sérieux pour commencer à migrer ailleurs. Plusieurs alternatives ont déjà été mentionnées (et répétées) dans ce fil.

Salut à tous, j'ai aussi eu ces problèmes obsolètes
donc ce que j'ai fait, c'est désinstaller nodejs et télécharger les dernières fonctionnalités de nodejs
qui est 14.10.1 Dernières fonctionnalités actuelles
https://nodejs.org/en/

et supprimez tous ces npm globaux installés que vous avez sur l'ordinateur

et c'est tout...

tous ceux qui sont obsolètes sont partis...

@acatzk wtf lmao

Cette bibliothèque est obsolète . S'il y a un bug, rien ne sera fait pour le corriger. S'il y a un problème de sécurité, rien ne sera fait pour le résoudre.

Vous ne devriez pas l'utiliser.

@davwheat merci

quelles sont les alternatives de ce module de requête ?

Choses que nous pourrions faire - s'il vous plaît discuter et faire du bénévolat!

• [ ] mettre à jour le fichier readme avec l'état actuel du projet
• [ ] mettre à jour le pipeline de publication ci @mikeal
• [ ] fournit un document contenant des conseils sur les request alternatives #3143
• [ ] ajoute un message d'avertissement à l'installation du package pour utiliser un autre package et référencer la doc
• [ ] choisissez une date pour arrêter le support (je vote 6 mois, mais 12 est probablement plus convivial)
• [ ] ferme toutes les demandes de fonctionnalités et les propositions de fonctionnalités
• [ ] réviser et fusionner les corrections de bogues pertinentes
• [ ] ajouter un problème github et des modèles pr expliquant que les fonctionnalités ne seront pas fusionnées
• [ ] désapprouve la prochaine version majeure ( 3.x ) afin que le projet en maintenance active reçoive un avertissement, mais les projets plus anciens continuent comme d'habitude

Des mises à jour sur qui fait quoi à ce stade ?

Pour ceux qui recherchent une alternative solide et prise en charge par Google (à part celles de https://github.com/request/request/issues/3143), je recommande fortement https://github.com/googleapis/gaxios. Je l'ai utilisé dans un projet récent et il est excellent jusqu'à présent.

Quelles sont les alternatives ? Votre page npm dit For more information about why request is deprecated and possible alternatives refer to {the link to this page}

3143

Registre npm WARN Utilisation de données obsolètes de https://registry.npmjs.org/ en raison d'une erreur de demande lors de la revalidation.
npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142

@thbestforyourbizdeployment oui.

Merci.

Pouvez-vous m'aider?

npm WARN obsolète [email protected] : la demande a été obsolète, voir https://github.com/request/request/issues/3142
npm WARN obsolète [email protected] : cette bibliothèque n'est plus prise en charge
npm ERR ! code EEXIST
npm ERR ! lien symbolique d'appel système
npm ERR ! chemin ../lib/node_modules/firebase-tools/lib/bin/firebase.js
npm ERR ! dest /usr/local/bin/firebase
npm ERR ! errno -17
npm ERR ! EEXIST : le fichier existe déjà, lien symbolique '../lib/node_modules/firebase-tools/lib/bin/firebase.js' -> '/usr/local/bin/firebase'
npm ERR ! Le fichier existe : /usr/local/bin/firebase
npm ERR ! Supprimez le fichier existant et réessayez, ou exécutez npm
npm ERR ! avec --force pour écraser les fichiers imprudemment.

npm ERR ! Un journal complet de cette course peut être trouvé dans:
npm ERR ! /Users/bahar/.npm/_logs/2020-11-18T17_07_43_310Z-debug.log

@baharozcelik Il n'y a rien pour vous aider.

Lire. Problème.

sudo npm install --global gulp-cli
essaie comme ça