Definitelytyped: @types/superagent error TS2304: No se puede encontrar el nombre 'XMLHttpRequest'.

¿Usas la opción --lib dom para tsc?

No, no lo hago. Y no estoy seguro de si esto ayuda, pero en realidad mi dependencia directa es superprueba. Lo uso para la prueba unitaria del código del lado del servidor.

@vvakame — Agregar "dom" a mi matriz compilerOptions.lib en tsconfig.json funcionó. Esto parece un poco contradictorio. ¿Debería ser este el comportamiento esperado o es solo una solución temporal?

descargo de responsabilidad: no soy un usuario superagente.
Creo que es el comportamiento esperado.

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

navegador / nodo HTTP elegante y rico en funciones con una API fluida

solución alterna.

interface XMLHttpRequest {}

El único problema que tengo al agregar "dom" a mi tsconfig.json es que no tenía una sección de lib en mi archivo, y ahora que la tengo, necesito incluirla otras librerías por defecto como "es2016" .

¿Tal vez hay una forma automatizada de arreglar esto? que no requiere modificar tsconfig.json ?

agregar ["dom", "es2017"] a lib solucionó esto.

El único problema que tengo al agregar "dom" a mi tsconfig.json es que estoy escribiendo el código del lado del servidor. Por lo tanto, no tiene ningún sentido para mí agregar esa lib. XMLHttpRequest no se envía con Node.js y el paquete superagent no generó un error en Node.js. El problema es que el paquete @typings no usa XMLHttpRequest condicionalmente, creo. Si el paquete funciona bien en Node.js y el navegador, @typings también debería funcionar bien.

Me encontré con esto hoy también. Si no podemos proporcionar/excluir condicionalmente ciertos tipos, ¿deberíamos considerar proporcionar dos versiones de estos tipos para el uso de nodos y dom?

Puede agregar un archivo superagent.d.ts con estos contenidos:

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

@vvakame realmente no es un 'comportamiento esperado' para una biblioteca diseñada para el uso de nodos o DOM para requerir tipeos para ambos en ambos entornos. El uso de esta biblioteca requiere que las personas agreguen tipos que fácilmente podrían causar errores, ya que no verá las advertencias del compilador al acceder a los elementos globales del navegador en el nodo.

También nos ha mordido esto en https://github.com/strongloop/loopback-next . Al agregar dom lib, el espacio de nombres global se contamina repentinamente con tipos como Request que no existen en Node.js

Estamos escribiendo la pila del servidor HTTP, por lo que generalmente hacemos import {ServerRequest as Request} from 'http' . Sin embargo, cuando esta línea se omite accidentalmente, o ServerRequest no tiene un alias como Request , TypeScript compila felizmente nuestro código y el error se detecta solo en tiempo de ejecución. En otras palabras, TypeScript ya no puede detectar errores en tiempo de compilación, lo que anula el propósito.

Estoy comenzando un nuevo proyecto, y pensé que sería inteligente y solucionaría esto cambiando de supertest a chai-http, pero chai-http usa @types/supertest. -_-

Aquí hay una especie de solución alternativa: https://github.com/jwalton/node-supertest-fetch

¿Alguna actualización sobre esto o no habrá una solución? Creo que @zephyrec lo expresó mejor, mucha gente está usando esto para el lado del servidor (es decir, nodo).

¿Alguna actualización sobre esto?

Una solución simple es usar una configuración de mecanografiado diferente para ejecutar las pruebas que amplíe su original y lo modifique. Entonces creas el archivo tsconfig.test.json :

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

(alternativamente, puede configurar el indicador del compilador skipLibCheck:true en lugar de ajustar las bibliotecas y eso omitirá la verificación de tipos para todos los node_modules )

Si está usando ts-jest , puede decirle que use su configuración a través de

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

De esta manera, no sacrifica la seguridad de tipo en su código normal, lo que definitivamente no es posible (dejaría supertest en un abrir y cerrar de ojos antes de hacerlo).

https://github.com/DefinitelyTyped/DefinitelyTyped/pull/33517 corrige este problema, pero ese PR se evita al fusionarse por un error

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

Interpreto que esto significa que @types/superagent no puede actualizar su requisito de TypeScript a 3.0+ hasta que todos los paquetes de @types que dependen de @types/superagent también hayan actualizado su requisito de TypeScript a 3.0+. Para mí, eso parece una falla en el sistema @types porque relaciona mi versión de TypeScript con la versión más antigua de TypeScript de todas las cosas que dependen de mí.

¿Alguien por ahí puede confirmar mi comprensión de ese mensaje de error y, de ser así, hay alguna forma de evitarlo?

En ausencia de una mejor solución permanente como en ese PR, resolví el problema en mi aplicación haciendo así:

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

Esa directiva lib de "triple barra" funcionará en TypeScript versión 3.0+.

¡Han pasado casi 2,5 años desde que se abrió este número! ¿Cómo podemos resolver esto?

FWIW, el problema desaparece cuando habilita la opción del compilador de TypeScript skipLibCheck .

Cuando skipLibCheck está habilitado, TypeScript no verificará ningún archivo .d.ts , tanto de dependencias como @types/superagent como de cualquier archivo .d.ts que pueda tener en su proyecto. Puede eliminar dom de sus bibliotecas y el compilador ya no se quejará.

Como un buen efecto secundario, skipLibCheck generalmente también mejora significativamente la velocidad de construcción.

@bajtos Eso puede abrirlo a errores, ya que reduce la seguridad de tipo.

• lib: [ "es6" ] funcionó
• target: "es2016+" también funcionó para mí

@G-Rath A menos que lo malinterprete, skipLibCheck no reducirá la seguridad de tipo de su código, solo de los archivos d.ts, la mayoría de los cuales probablemente sean parte de los módulos de nodo y no de su código de todos modos.

Con respecto a skipLibCheck, esa no es una solución viable en mi opinión. De https://stackoverflow.com/questions/52311779/usage-of-the-typescript-compiler-argument-skiplibcheck "dependiendo de cuáles fueron los errores, el compilador puede recuperarse de ellos de una manera que cause problemas en otras partes del código pasar desapercibido (por ejemplo, reemplazando un tipo erróneo con cualquier otro), por lo tanto, suprimir los errores de tipo (ya sea por --skipLibCheck, //@ts-ignore, o cualquier otro medio) es una práctica arriesgada"

@carnesen me apostó a ello - esa era exactamente la pregunta de stackoverflow que iba a citar :joy:

@rjmunro ahí lo tienes 😃

No es tan malo como // @ts-ignore , pero cualquier cosa que suprima los errores tipográficos, sin importar qué tan raro sea, técnicamente debilita la seguridad tipográfica de su código, especialmente porque su carpeta node_modules está compuesta por .d.ts archivos que TS usa para escribir todo.

Creo que la solución más limpia es PR #33517 de @carnesen que agrega la biblioteca dom como referencia externa a la definición de tipo superagent , ya que las referencias a Blob y XMLHttpRequest son requeridos por las definiciones de tipo superagent pero no por su implementación, dependiendo de la forma en que se use (_navegador vs nodo_).

El único inconveniente real es que la referencia lib requiere la versión 3.0.0 de TypeScript, que se lanzó hace aproximadamente 9 meses.
No estoy seguro de si esto solo afectaría a chai-http (ver Travis-CI ) o si hay otras dependencias que necesitarían que su versión mecanografiada se pasara a 3.0.0

¿Alguna actualización? Es de nuevo 2 meses después...

Después de leer todo esto, la solución más limpia disponible actualmente es de @carnesen pero no me funciona :-(

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

También revisé su PR (https://github.com/DefinitelyTyped/DefinitelyTyped/pull/33517) pero el error de TravisCI no tiene sentido porque chai-http no requiere una versión de TS inferior a 3.0...

Soy bastante nuevo en TypeScript, así que si estoy haciendo algo mal, házmelo saber. Acabo de enviar exactamente el mismo código que @carnesen hizo en un nuevo PR para profundizar en los registros de Travis CI (https://github.com/DefinitelyTyped/DefinitelyTyped/pull/36282)

EDITAR:

parece que chai-http ya no es el problema, pero promisify-supertest lo es... parece un paquete abandonado no muy popular (https://github.com/ariporad/promisify-supertest/blob /maestro/prueba/index.js)

¿Cuál es el proceso para actualizar esto?

EDITAR 2:

Profundicé más y descubrí que las siguientes definiciones de tipo deben actualizarse:

• promisify-supertest
• nodo-cw simple
• superagente-bunyan
• Superagente sin caché
• prefijo-superagente
• superprueba

// error TS2304: No se puede encontrar el nombre 'XMLHttpRequest'
declarar interfaz XMLHttpRequest {}
// error TS2304: No se puede encontrar el nombre 'Blob'
declarar interfaz Blob {}

@JasonKleban , ¿dónde va este archivo? En node_modules > superagent ? He estado tratando de resolver esto y estoy al final de mi ingenio.

@mikeyamato : no recuerdo dónde lo usé con éxito, pero no en node_modules ya que no administra esos archivos usted mismo. En cambio, probablemente esté junto a sus otros archivos fuente. Habrías intentado eso primero, supongo. ¿Ningún cambio?

¿También puede experimentar con la configuración de la carpeta de escritura tsconfig.json?

EDITAR: abrió un nuevo problema para rastrear esto: # 41425

Con la fusión de #36282, surge un nuevo problema. Al usar superagent en un proyecto de solo nodo, la introducción de la directiva de barra triple

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

da como resultado que los tipos de DOM se agreguen de forma transparente al proyecto. Sin embargo, dado que este es un proyecto de solo nodo, no hay DOM, por lo que el código como

window.setTimeout()

debería dar como resultado un error de TypeScript. Dado que los tipos de DOM se incluyen de forma silenciosa, este no es el caso y puede generar errores sutiles en la base de código.

¿Hay alguna manera de que podamos incluir tipeos de solo nodo o solo de navegador en un proyecto, para que podamos elegir cuál usar?

Otro efecto secundario de tener una dependencia es dom es que evita que supertest ( superagent ) se use en un proyecto con lib: webworker , ref: https: //github.com/microsoft/TypeScript/issues/20595. Por lo que puedo ver, esto no se ha mencionado antes.

$ npm i @types/ superagent@latest -D

¡Debería hacer el truco!