Definitelytyped: @types/superaagent error TS2304: Der Name „XMLHttpRequest“ kann nicht gefunden werden.

Verwenden Sie die Option --lib dom für tsc?

Nein, ich nicht. Und ich bin mir nicht sicher, ob das hilft, aber in Wirklichkeit ist meine direkte Abhängigkeit Supertest. Ich verwende es für Komponententests für serverseitigen Code.

@vvakame — Das Hinzufügen "dom" zu meinem compilerOptions.lib -Array in tsconfig.json hat den Zweck erfüllt. Dies scheint ein wenig kontraintuitiv. Sollte dies das erwartete Verhalten sein oder ist dies nur eine vorübergehende Problemumgehung?

Haftungsausschluss: Ich bin kein Superagent-Benutzer.
Ich denke, es ist erwartetes Verhalten.

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

eleganter und funktionsreicher Browser/Knoten HTTP mit einer fließenden API

herumarbeiten.

interface XMLHttpRequest {}

Das einzige Problem, das ich beim Hinzufügen "dom" zu meinem tsconfig.json habe, ist, dass ich keinen lib -Abschnitt in meiner Datei hatte, und jetzt, da ich ihn habe, muss ich ihn einfügen andere Bibliotheken standardmäßig wie "es2016" .

Vielleicht gibt es eine automatisierte Möglichkeit, dies zu beheben? was keine Änderung tsconfig.json erfordert?

Das Hinzufügen ["dom", "es2017"] zu lib hat dies behoben.

Das einzige Problem, das ich beim Hinzufügen von "dom" zu meiner tsconfig.json habe, ist, dass ich serverseitigen Code schreibe. Daher macht es für mich keinen Sinn, diese lib hinzuzufügen. XMLHttpRequest wird nicht mit Node.js geliefert, und das Superagent-Paket hat bei Node.js keinen Fehler ausgelöst. Das Problem besteht darin, dass das @typings -Paket XMLHttpRequest nicht bedingt verwendet, denke ich. Wenn das Paket auf Node.js und dem Browser gut funktioniert, sollten die @Typings auch gut funktionieren.

bin heute auch darauf gestoßen. Wenn wir bestimmte Typen nicht bedingt bereitstellen/ausschließen können, sollten wir in Betracht ziehen, zwei Versionen dieser Typen für die Knoten- und Dom-Nutzung bereitzustellen?

Sie können eine superagent.d.ts-Datei mit folgendem Inhalt hinzufügen:

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

@vvakame Es ist wirklich kein "erwartetes Verhalten" für eine Bibliothek, die für die Verwendung von Knoten oder DOM entwickelt wurde, um in beiden Umgebungen Eingaben für beide zu erfordern. Die Verwendung dieser Bibliothek erfordert, dass Benutzer Eingaben hinzufügen, die leicht Fehler verursachen können, da Sie keine Compiler-Warnungen sehen, wenn Sie auf Browser-Globals in node.

Wir wurden auch in https://github.com/strongloop/loopback-next davon gebissen. Durch das Hinzufügen von dom lib wird der globale Namensraum plötzlich mit Typen wie Request verschmutzt, die in Node.js nicht vorhanden sind

Wir schreiben einen HTTP-Server-Stack, also machen wir normalerweise import {ServerRequest as Request} from 'http' . Wenn diese Zeile jedoch versehentlich ausgelassen wird oder ServerRequest nicht als Request aliasiert ist, kompiliert TypeScript unseren Code problemlos und der Fehler wird erst zur Laufzeit erkannt. Mit anderen Worten, TypeScript ist nicht mehr in der Lage, Fehler zur Kompilierzeit abzufangen, was den Zweck verfehlt.

Ich starte gerade ein neues Projekt und dachte, ich wäre schlau und würde dies umgehen, indem ich von Supertest zu Chai-http wechsele, aber Chai-http verwendet @types/supertest. -_-

Wir werden, hier ist eine Art Workaround: https://github.com/jwalton/node-supertest-fetch

Irgendwelche Updates dazu oder wird es keine Lösung geben? Ich denke, @zephyrec hat es am besten ausgedrückt, viele Leute verwenden dies für die Serverseite (dh den Knoten).

Irgendwelche Updates dazu?

Eine einfache Problemumgehung besteht darin, eine andere Typskriptkonfiguration zum Ausführen der Tests zu verwenden, die Ihr Original erweitert und optimiert. Sie erstellen also die Datei tsconfig.test.json :

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

(Alternativ könnten Sie einfach das Compiler-Flag skipLibCheck:true setzen, anstatt die Bibliotheken zu optimieren, und das überspringt die Typprüfung für alle node_modules )

Wenn Sie ts-jest verwenden, können Sie ihm sagen, dass es Ihre Konfiguration über verwenden soll

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

Auf diese Weise opfern Sie die Typsicherheit in Ihrem regulären Code nicht, was definitiv ein No-Go ist (ich würde Supertest sofort fallen lassen, bevor ich das tue).

https://github.com/DefinitelyTyped/DefinitelyTyped/pull/33517 behebt dieses Problem, aber das PR wird durch das Zusammenführen durch einen Fehler verhindert

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

Ich interpretiere dies so, dass @types/superagent seine TypeScript-Anforderung nicht auf 3.0+ aktualisieren kann, bis alle @types-Pakete, die von @types/ superagent abhängen, ihre TypeScript-Anforderung ebenfalls auf 3.0+ aktualisiert haben. Für mich scheint das ein Fehler im @types -System zu sein, weil es meine TypeScript-Version an die älteste TypeScript-Version all der Dinge koppelt, die von mir abhängen.

Kann jemand da draußen mein Verständnis dieser Fehlermeldung bestätigen, und wenn ja, gibt es eine Möglichkeit, sie zu umgehen?

In Ermangelung einer besseren dauerhaften Lösung wie in dieser PR habe ich das Problem in meiner Anwendung folgendermaßen gelöst:

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

Diese „triple-slash“ lib-Direktive funktioniert in TypeScript Version 3.0+.

Es ist fast 2,5 Jahre her, seit diese Ausgabe geöffnet wurde! Wie können wir das lösen.

FWIW, das Problem verschwindet, wenn Sie die Compiler-Option skipLibCheck TypeScript aktivieren.

Wenn skipLibCheck aktiviert ist, überprüft TypeScript keine .d.ts -Dateien – sowohl von Abhängigkeiten wie @types/superagent als auch von .d.ts -Dateien, die Sie möglicherweise in Ihrem Projekt haben. Sie können dom aus Ihren Bibliotheken entfernen und der Compiler wird sich nicht mehr beschweren.

Als netter Nebeneffekt verbessert skipLibCheck normalerweise auch die Build-Geschwindigkeit erheblich.

@bajtos Das kann Sie für Fehler öffnen, da es die Typsicherheit verringert.

• lib: [ "es6" ] hat funktioniert
• target: "es2016+" hat auch bei mir funktioniert

@G-Rath Sofern ich es nicht falsch verstehe, wird skipLibCheck die Typsicherheit Ihres Codes nicht verringern, sondern nur von d.ts-Dateien, von denen die meisten wahrscheinlich Teil von Knotenmodulen und sowieso nicht Ihres Codes sind.

In Bezug auf skipLibCheck ist dies meiner Meinung nach keine praktikable Problemumgehung. Von https://stackoverflow.com/questions/52311779/usage-of-the-typescript-compiler-argument-skiplibcheck „Je nachdem, was die Fehler waren, kann der Compiler sie auf eine Weise beheben, die an anderer Stelle im Code Probleme verursacht unbemerkt zu bleiben (z. B. durch Ersetzen eines fehlerhaften Typs durch einen beliebigen), daher ist das Unterdrücken von Typfehlern (ob durch --skipLibCheck, //@ts-ignore oder auf andere Weise) eine riskante Praxis.

@carnesen du hast mich darauf gesetzt - das war genau die Stackoverflow-Frage, die ich zitieren wollte :joy:

@rjmunro da gehst du 😃

Es ist nicht so schlimm wie // @ts-ignore , aber alles, was Typfehler unterdrückt, egal wie selten, schwächt technisch gesehen die Typsicherheit Ihres Codes, zumal Ihr Ordner node_modules aus .d.ts besteht

Ich denke, die sauberste Lösung ist wirklich die PR #33517 von @carnesen , die die Bibliothek dom als externe Referenz zur Typdefinition superagent hinzufügt, da die Referenzen auf Blob und XMLHttpRequest werden von den Typdefinitionen von superagent benötigt, aber nicht von ihrer Implementierung, abhängig von der Art und Weise, wie sie verwendet werden (_browser vs node_).

Der einzige wirkliche Nachteil ist, dass die lib-Referenz Typoskript-Version 3.0.0 erfordert, die vor ungefähr 9 Monaten veröffentlicht wurde.
Ich bin mir nicht sicher, ob dies nur chai-http (siehe Travis-CI ) betreffen würde oder ob es andere Abhängigkeiten gibt, deren Typescript-Version auf 3.0.0 erhöht werden müsste

Irgendwelche Neuigkeiten? 2 Monate später ist es wieder soweit...

Nachdem ich das alles gelesen habe, ist die sauberste Lösung, die derzeit verfügbar ist, von @carnesen , funktioniert aber nicht für mich :-(

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

Ich habe auch seine PR überprüft (https://github.com/DefinitelyTyped/DefinitelyTyped/pull/33517), aber der TravisCI-Fehler ergibt keinen Sinn, da chai-http keine TS-Version niedriger als 3.0 erfordert ...

Ich bin ziemlich neu bei TypeScript, also lass es mich wissen, wenn ich etwas falsch mache. Ich habe gerade genau den gleichen Code eingereicht, den @carnesen in einer neuen PR eingereicht hat, um tiefer in die Travis CI-Protokolle einzudringen (https://github.com/DefinitelyTyped/DefinitelyTyped/pull/36282).

BEARBEITEN:

Es sieht so aus, als ob chai-http nicht mehr das Problem ist, aber promisify-supertest ist ... es sieht aus wie ein nicht besonders beliebtes verlassenes Paket (https://github.com/ariporad/promisify-supertest/blob /master/test/index.js)

Wie ist der Prozess für die Aktualisierung?

BEARBEITEN 2:

Ich habe tiefer gegraben und festgestellt, dass die folgenden Typdefinitionen aktualisiert werden müssen:

• Promisify-Supertest
• simple-cw-Knoten
• superagent-bunyan
• superagent-no-cache
• Superagent-Präfix
• Supertest

// Fehler TS2304: Kann Name 'XMLHttpRequest' nicht finden
Schnittstelle XMLHttpRequest deklarieren {}
// Fehler TS2304: Name 'Blob' kann nicht gefunden werden
Schnittstelle deklarieren Blob {}

@JasonKleban wo geht diese Datei hin? In node_modules > superagent ? Ich habe versucht, das herauszufinden, und ich bin mit meinem Latein am Ende.

@miceyamato - Ich kann mich nicht erinnern, wo ich es erfolgreich verwendet habe, aber nicht in node_modules, da Sie diese Dateien nicht selbst verwalten. Stattdessen befindet es sich wahrscheinlich nur neben Ihren anderen Quelldateien. Das hättest du zuerst versucht, nehme ich an. Keine Änderung?

Sie können auch mit der Einstellung des Typings-Ordners tsconfig.json experimentieren?

BEARBEITEN: Neues Problem geöffnet, um dies zu verfolgen: #41425

Mit der Zusammenführung von #36282 gibt es ein neues Problem. Bei Verwendung von Superagent in einem Nur-Knoten-Projekt die Einführung der Triple-Slash-Direktive

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

führt dazu, dass die DOM-Typisierungen transparent zum Projekt hinzugefügt werden. Da dies jedoch ein Node-Only-Projekt ist, gibt es kein DOM, und daher Code wie z

window.setTimeout()

sollte zu einem TypeScript-Fehler führen. Da die DOM-Typisierungen stillschweigend enthalten sind, ist dies nicht der Fall und kann zu subtilen Fehlern in der Codebasis führen.

Gibt es eine Möglichkeit, Node-Only- oder Browser-Only-Eingaben in ein Projekt einzufügen, damit wir auswählen können, welche wir verwenden möchten?

Ein weiterer Nebeneffekt einer Abhängigkeit von dom ist, dass es verhindert, dass supertest ( superagent ) in einem Projekt mit lib: webworker verwendet wird, ref: https: //github.com/microsoft/TypeScript/issues/20595. Soweit ich sehen kann, wurde dies bisher nicht erwähnt.

$ npm i @types/ superagent@latest -D

Sollte den Trick machen!