Definitelytyped: Erreur @types/superagent TS2304 : Impossible de trouver le nom 'XMLHttpRequest'.

Utilisez-vous l'option --lib dom pour tsc ?

Non, je ne sais pas. Et je ne sais pas si cela aide, mais en réalité, ma dépendance directe est supertest. Je l'utilise pour le code côté serveur de test unitaire.

@vvakame - L'ajout "dom" à mon tableau compilerOptions.lib dans tsconfig.json a fait l'affaire. Cela semble un peu contre-intuitif. Cela devrait-il être le comportement attendu ou s'agit-il simplement d'une solution de contournement temporaire?

avis de non-responsabilité : je ne suis pas un super-utilisateur.
Je pense que c'est un comportement attendu.

https://www.npmjs.com/package/superagent

navigateur / nœud HTTP élégant et riche en fonctionnalités avec une API fluide

solution de contournement.

interface XMLHttpRequest {}

Le seul problème que j'ai avec l'ajout "dom" à mon tsconfig.json est que je n'avais pas de section lib dans mon fichier, et maintenant que je l'ai, je dois inclure d'autres bibliothèques par défaut comme "es2016" .

Peut-être y a-t-il un moyen automatisé de résoudre ce problème ? qui ne nécessite pas de modifier tsconfig.json ?

l'ajout ["dom", "es2017"] à lib a corrigé ce problème.

Le seul problème que j'ai avec l'ajout de "dom" à mon tsconfig.json est que j'écris du code côté serveur. Par conséquent, cela n'a aucun sens pour moi d'ajouter cette lib. XMLHttpRequest n'est pas livré avec Node.js et le package superagent n'a pas généré d'erreur sur Node.js. Le problème est que le package @typings n'utilise pas XMLHttpRequest de manière conditionnelle, je pense. Si le package fonctionne bien sur Node.js et le navigateur, les @typings devraient également fonctionner correctement.

s'est également heurté à cela aujourd'hui. Si nous ne pouvons pas fournir/exclure conditionnellement certains types, devrions-nous envisager de fournir deux versions de ces types pour l'utilisation des nœuds et des dom ?

Vous pouvez ajouter un fichier superagent.d.ts avec ces contenus :

// error TS2304: Cannot find name 'XMLHttpRequest'
declare interface XMLHttpRequest {}
// error TS2304: Cannot find name 'Blob'
declare interface Blob {}

@vvakame ce n'est vraiment pas un "comportement attendu" pour une bibliothèque conçue pour un nœud ou une utilisation DOM pour exiger des typages pour les deux dans les deux environnements. L'utilisation de cette bibliothèque nécessite que les utilisateurs ajoutent des typages qui pourraient facilement provoquer des bogues, car vous ne verrez pas les avertissements du compilateur lors de l'accès aux globals du navigateur dans node.

Nous avons également été mordus par cela dans https://github.com/strongloop/loopback-next . En ajoutant dom lib, l'espace de noms global est soudainement pollué par des types comme Request qui n'existent pas dans Node.js

Nous écrivons une pile de serveurs HTTP, nous faisons donc généralement import {ServerRequest as Request} from 'http' . Cependant, lorsque cette ligne est accidentellement omise ou ServerRequest n'est pas alias Request , alors TypeScript compile joyeusement notre code et l'erreur est repérée uniquement au moment de l'exécution. En d'autres termes, TypeScript n'est plus en mesure de détecter les erreurs au moment de la compilation, ce qui va à l'encontre de l'objectif.

Je viens de commencer un nouveau projet, et j'ai pensé que je serais intelligent et que je contournerais cela en passant de supertest à chai-http, mais chai-http utilise @types/supertest. -_-

Nous allons, voici une sorte de solution de contournement : https://github.com/jwalton/node-supertest-fetch

Des mises à jour à ce sujet ou n'y aura-t-il pas de correctif? Je pense que @zephyrec l'a mieux dit, beaucoup de gens l'utilisent côté serveur (c'est-à-dire le nœud).

Des mises à jour à ce sujet ?

Une solution de contournement simple consiste à utiliser une configuration dactylographiée différente pour exécuter les tests qui étendent votre original et le modifient. Donc vous créez le fichier tsconfig.test.json :

{
  "extends": "./tsconfig.prod.json",
  "compilerOptions": {
    "lib": ["dom", "..."] // supertest requires dom for type definitions to work
  }
}

(alternativement, vous pouvez simplement définir l'indicateur de compilateur skipLibCheck:true au lieu de modifier les bibliothèques et cela évitera la vérification de type pour tous les node_modules )

Si vous utilisez ts-jest vous pouvez lui dire d'utiliser votre configuration via

"jest": {
        "globals": {
            "ts-jest": {
                "tsConfig": "tsconfig.test.json"
            }
        }
}

De cette façon, vous ne sacrifiez pas la sécurité du type dans votre code habituel, ce qui est définitivement interdit (je laisserais tomber le supertest en un clin d'œil avant de le faire).

https://github.com/DefinitelyTyped/DefinitelyTyped/pull/33517 corrige ce problème mais ce PR est empêché en étant fusionné par une erreur

chai-http depends on superagent but has a lower required TypeScript version

J'interprète cela comme signifiant que @types/superagent ne peut pas mettre à jour son exigence TypeScript vers 3.0+ jusqu'à ce que tous les packages @types qui dépendent de @types/superagent aient également mis à jour leur exigence TypeScript vers 3.0+. Pour moi, cela ressemble à une faille dans le système @types car il rattache ma version TypeScript à la version TypeScript la plus ancienne de toutes les choses qui dépendent de moi.

Est-ce que quelqu'un est en mesure de confirmer ma compréhension de ce message d'erreur et si oui, y a-t-il un moyen de le contourner?

En l'absence d'une meilleure solution permanente comme dans ce PR, j'ai résolu le problème dans mon application en procédant comme suit :

/// <reference lib="dom" />
import request = require('supertest');

Cette directive lib "triple barre oblique" fonctionnera dans TypeScript version 3.0+.

Cela fait presque 2,5 ans que ce numéro a été ouvert ! Comment pouvons-nous résoudre ce problème.

FWIW, le problème disparaît lorsque vous activez l'option de compilation de TypeScript skipLibCheck .

Lorsque skipLibCheck est activé, TypeScript ne vérifiera aucun fichier .d.ts - à la fois à partir de dépendances comme @types/superagent mais aussi de tout fichier .d.ts que vous pourriez avoir dans votre projet. Vous pouvez supprimer dom de vos bibliothèques et le compilateur ne se plaindra plus.

Comme effet secondaire agréable, skipLibCheck améliore également considérablement la vitesse de construction.

@bajtos Cela peut vous ouvrir à des erreurs, car cela réduit la sécurité du type.

• lib: [ "es6" ] travaillé
• target: "es2016+" a aussi fonctionné pour moi

@G-Rath Sauf erreur de ma part, skipLibCheck ne réduira pas la sécurité de type de votre code, uniquement des fichiers d.ts, dont la plupart font probablement partie des modules de nœud et non de votre code de toute façon.

En ce qui concerne skipLibCheck, ce n'est pas une solution de contournement viable IMO. De https://stackoverflow.com/questions/52311779/usage-of-the-typescript-compiler-argument-skiplibcheck "selon les erreurs, le compilateur peut les récupérer d'une manière qui cause des problèmes ailleurs dans le code passer inaperçu (par exemple, en remplaçant un type erroné par any), donc supprimer les erreurs de type (que ce soit par --skipLibCheck, //@ts-ignore, ou tout autre moyen) est une pratique risquée"

@carnesen vous m'avez parié - c'était la question exacte de stackoverflow que j'allais citer :joy:

@rjmunro voilà 😃

Ce n'est pas aussi grave que // @ts-ignore , mais tout ce qui supprime les erreurs de type, aussi rares soient-elles, affaiblit techniquement la sécurité des types de votre code, d'autant plus que votre dossier node_modules est composé de .d.ts Fichiers

Je pense que la solution la plus propre est vraiment le PR #33517 de @carnesen qui ajoute la bibliothèque dom comme référence externe à la définition de type superagent , puisque les références à Blob et XMLHttpRequest sont requis par les définitions de type superagent mais pas par son implémentation, selon la façon dont il est utilisé (_browser vs node_).

Le seul véritable inconvénient est que la référence lib nécessite la version 3.0.0 de Typescript qui a été publiée il y a environ 9 mois maintenant.
Je ne sais pas si cela n'affecterait que chai-http (voir Travis-CI ) ou s'il existe d'autres dépendances qui auraient besoin que leur version tapuscrit soit remplacée par 3.0.0

Les mises à jour? C'est encore 2 mois plus tard...

Après avoir lu tout cela, la solution la plus propre actuellement disponible provient de @carnesen mais ne fonctionne pas pour moi :-(

/// <reference lib="dom" />
import request = require('supertest');

J'ai également vérifié son PR (https://github.com/DefinitelyTyped/DefinitelyTyped/pull/33517) mais l'erreur TravisCI n'a pas de sens car chai-http ne nécessite pas une version TS inférieure à 3.0...

Je suis assez nouveau sur TypeScript, donc si je fais quelque chose de mal, faites-le moi savoir. Je viens de soumettre exactement le même code que @carnesen a fait dans un nouveau PR pour approfondir les journaux Travis CI (https://github.com/DefinitelyTyped/DefinitelyTyped/pull/36282)

ÉDITER:

il semble que chai-http ne soit plus le problème, mais promisify-supertest l'est... il ressemble à un paquet abandonné pas super populaire (https://github.com/ariporad/promisify-supertest/blob /master/test/index.js)

Quelle est la procédure de mise à jour ?

ÉDITION 2 :

J'ai creusé plus profondément et j'ai découvert que les définitions de type suivantes devaient être mises à jour :

• promesse-supertest
• nœud cw simple
• superagent-bunyan
• superagent sans cache
• préfixe-superagent
• supertest

// erreur TS2304 : Impossible de trouver le nom 'XMLHttpRequest'
déclarer l'interface XMLHttpRequest {}
// erreur TS2304 : Impossible de trouver le nom 'Blob'
déclarer l'interface Blob {}

@JasonKleban où va ce fichier ? Dans node_modules > superagent ? J'ai essayé de comprendre cela et je suis à bout de nerfs.

@mikeyamato - Je ne me souviens pas où je l'ai utilisé avec succès, mais pas dans node_modules puisque vous ne gérez pas ces fichiers vous-même. Au lieu de cela, c'est probablement juste à côté de vos autres fichiers source. Vous auriez essayé cela en premier, je suppose. Pas de changement?

Vous pouvez également expérimenter avec le paramètre de dossier de saisies tsconfig.json ?

EDIT : a ouvert un nouveau numéro pour suivre ceci : #41425

Avec la fusion de #36282, il y a un nouveau problème. Lors de l'utilisation de superagent dans un projet de nœud uniquement, l'introduction de la directive triple barre oblique

/// <reference lib="dom" />

entraîne l'ajout transparent des typages DOM au projet. Comme il s'agit d'un projet de nœud uniquement, cependant, il n'y a pas de DOM, et donc un code tel que

window.setTimeout()

devrait entraîner une erreur TypeScript. Étant donné que les typages DOM sont inclus en silence, ce n'est pas le cas et peut entraîner des bogues subtils dans la base de code.

Existe-t-il un moyen d'inclure des typages de nœud uniquement ou de navigateur uniquement dans un projet, afin que nous puissions choisir lequel utiliser ?

Un autre effet secondaire d'avoir une dépendance est dom est qu'il empêche supertest ( superagent ) d'être utilisé dans un projet avec lib: webworker , ref: https: //github.com/microsoft/TypeScript/issues/20595. Autant que je sache, cela n'a pas été mentionné auparavant.

$ npm i @types/ superagent@latest -D

Devrait faire l'affaire !