Definitelytyped: @types/superagent erro TS2304: Não é possível localizar o nome 'XMLHttpRequest'.

Você usa a opção --lib dom para tsc?

Não, eu não. E não tenho certeza se isso ajuda, mas na realidade minha dependência direta é supertest. Eu o uso para o código do lado do servidor de teste de unidade.

@vvakame — Adicionar "dom" ao meu array compilerOptions.lib em tsconfig.json funcionou. Isso parece um pouco contra-intuitivo. Esse deve ser o comportamento esperado ou é apenas uma solução temporária?

isenção de responsabilidade: não sou usuário superagente.
Acho que é um comportamento esperado.

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

navegador / nó HTTP elegante e rico em recursos com uma API fluente

Gambiarra.

interface XMLHttpRequest {}

O único problema que tenho ao adicionar "dom" ao meu tsconfig.json é que eu não tinha uma seção lib no meu arquivo, e agora que tenho, preciso incluir outras bibliotecas por padrão como "es2016" .

Talvez haja uma maneira automatizada de corrigir isso? que não requer a modificação tsconfig.json ?

adicionando ["dom", "es2017"] à lib corrigiu isso.

O único problema que tenho ao adicionar "dom" ao meu tsconfig.json é que estou escrevendo o código do lado do servidor. Portanto, não faz sentido para mim adicionar essa lib. XMLHttpRequest não é enviado com o Node.js e o pacote superagent não gerou um erro no Node.js. O problema é com o pacote @typings não usando XMLHttpRequest condicionalmente, eu acho. Se o pacote funciona bem no Node.js e no navegador, o @typings deve funcionar bem também.

passou por isso hoje também. Se não pudermos fornecer/excluir condicionalmente certos tipos, devemos considerar fornecer duas versões desses tipos para uso de node e dom?

Você pode adicionar um arquivo superagent.d.ts com este conteúdo:

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

@vvakame não é realmente 'comportamento esperado' para uma biblioteca projetada para uso de nó ou DOM exigir tipagens para ambos em ambos os ambientes. O uso desta biblioteca requer que as pessoas adicionem tipos que podem facilmente causar bugs, pois você não verá avisos do compilador ao acessar globais do navegador em node.

Também fomos mordidos por isso em https://github.com/strongloop/loopback-next . Ao adicionar dom lib, o namespace global é repentinamente poluído com tipos como Request que não existem no Node.js

Estamos escrevendo uma pilha de servidores HTTP, então geralmente fazemos import {ServerRequest as Request} from 'http' . No entanto, quando esta linha é omitida acidentalmente, ou ServerRequest não é alias como Request , o TypeScript compila nosso código com prazer e o erro é detectado apenas em tempo de execução. Em outras palavras, o TypeScript não é mais capaz de detectar erros em tempo de compilação, o que anula o propósito.

Estou começando um novo projeto e pensei que seria inteligente e contornaria isso mudando de supertest para chai-http, mas chai-http usa @types/supertest. -_-

Vamos, aqui está uma solução alternativa: https://github.com/jwalton/node-supertest-fetch

Alguma atualização sobre isso ou não vai haver uma correção? Acho que @zephyrec colocou melhor, muitas pessoas estão usando isso para o lado do servidor (ou seja, nó).

Alguma atualização sobre isso?

Uma solução simples é usar uma configuração de texto datilografado diferente para executar os testes que estendem seu original e o ajustam. Então você cria o arquivo tsconfig.test.json :

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

(alternativamente, você pode apenas definir o sinalizador do compilador skipLibCheck:true em vez de ajustar as bibliotecas e isso pulará a verificação de tipos para todos os node_modules )

Se você estiver usando ts-jest você pode dizer para usar sua configuração via

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

Dessa forma, você não sacrifica a segurança de tipo em seu código regular, o que definitivamente é impossível (eu abandonaria o superteste em um piscar de olhos antes de fazer isso).

https://github.com/DefinitelyTyped/DefinitelyTyped/pull/33517 corrige esse problema, mas esse PR é impedido por ser mesclado por um erro

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

Eu interpreto isso como significando que @types/superagent não pode atualizar seu requisito TypeScript para 3.0+ até que todos os pacotes @types que dependem de @types/superagent também tenham atualizado seu requisito TypeScript para 3.0+. Para mim, isso parece uma falha no sistema @types porque vincula minha versão do TypeScript à versão mais antiga do TypeScript de todas as coisas que dependem de mim.

Alguém pode confirmar minha compreensão dessa mensagem de erro e, em caso afirmativo, existe alguma maneira de contornar isso?

Na ausência de uma correção permanente melhor como naquele PR, resolvi o problema no meu aplicativo da seguinte forma:

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

Essa diretiva lib "triple-slash" funcionará no TypeScript versão 3.0+.

Já se passaram quase 2,5 anos desde que esta edição foi aberta! Como podemos resolver isso.

FWIW, o problema desaparece quando você ativa a opção de compilador do TypeScript skipLibCheck .

Quando skipLibCheck estiver habilitado, o TypeScript não verificará nenhum arquivo .d.ts - tanto de dependências como @types/superagent mas também de qualquer arquivo .d.ts que você possa ter em seu projeto. Você pode remover dom de suas libs e o compilador não reclamará mais.

Como um bom efeito colateral, skipLibCheck geralmente também melhora significativamente a velocidade de construção.

@bajtos Isso pode gerar erros, pois reduz a segurança do tipo.

• lib: [ "es6" ] trabalhou
• target: "es2016+" também funcionou para mim

@G-Rath A menos que eu entenda mal, skipLibCheck não reduzirá a segurança de tipo do seu código, apenas dos arquivos d.ts, a maioria dos quais provavelmente faz parte dos módulos do nó e não do seu código.

Em relação ao skipLibCheck, essa não é uma solução alternativa viável IMO. De https://stackoverflow.com/questions/52311779/usage-of-the-typescript-compiler-argument-skiplibcheck "dependendo de quais foram os erros, o compilador pode se recuperar deles de uma maneira que causa problemas em outras partes do código passar despercebido (por exemplo, substituindo um tipo errado por qualquer), portanto, suprimir erros de tipo (seja por --skipLibCheck, //@ts-ignore ou qualquer outro meio) é uma prática arriscada"

@carnesen você me apostou nisso - essa era a pergunta exata do stackoverflow que eu ia citar :joy:

@rjmunro lá vai 😃

Não é tão ruim quanto // @ts-ignore , mas qualquer coisa que suprima erros de tipo, não importa quão raramente, enfraquece tecnicamente a segurança de tipo do seu código, especialmente porque sua pasta node_modules é composta de .d.ts arquivos que TS usa para digitar tudo.

Acho que a solução mais limpa realmente é a PR #33517 de @carnesen que adiciona a biblioteca dom como referência externa à definição de tipo superagent , já que as referências a Blob e XMLHttpRequest são exigidos pelas definições de tipo superagent , mas não por sua implementação, dependendo da forma de uso (_browser vs node_).

A única desvantagem real é que a referência lib requer typescript versão 3.0.0, que foi lançada há cerca de 9 meses.
Não tenho certeza se isso afetaria apenas chai-http (consulte Travis-CI ) ou se existem outras dependências que precisariam que sua versão do typescript fosse aumentada para 3.0.0

Alguma atualização? É novamente 2 meses depois...

Depois de ler tudo isso, a solução mais limpa atualmente disponível é da @carnesen , mas não funciona para mim :-(

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

Eu também verifiquei seu PR (https://github.com/DefinitelyTyped/DefinitelyTyped/pull/33517) mas o erro TravisCI não faz sentido porque chai-http não requer uma versão TS inferior a 3.0...

Eu sou muito novo no TypeScript, então se eu estiver fazendo algo errado me avise. Acabei de enviar exatamente o mesmo código que @carnesen fez em um novo PR para aprofundar os logs do Travis CI (https://github.com/DefinitelyTyped/DefinitelyTyped/pull/36282)

EDITAR:

parece que chai-http não é mais o problema, mas promisify-supertest é... parece um pacote abandonado não super popular (https://github.com/ariporad/promisify-supertest/blob /master/test/index.js)

Qual é o processo para atualizar isso?

EDIÇÃO 2:

Eu cavei mais fundo e descobri que as seguintes definições de tipo precisam ser atualizadas:

• prometer-superteste
• nó-cw-simples
• superagente-bunyan
• superagente sem cache
• prefixo do superagente
• superteste

// erro TS2304: Não é possível encontrar o nome 'XMLHttpRequest'
declarar a interface XMLHttpRequest {}
// erro TS2304: Não é possível encontrar o nome 'Blob'
declarar interface Blob {}

@JasonKleban para onde vai esse arquivo? Em node_modules > superagent ? Eu tenho tentado descobrir isso e estou no meu juízo final.

@mikeyamato - não me lembro onde o usei com sucesso, mas não em node_modules, pois você não gerencia esses arquivos sozinho. Em vez disso, provavelmente está apenas ao lado de seus outros arquivos de origem. Você teria tentado isso primeiro, eu suponho. Nenhuma mudança?

Você também pode experimentar a configuração da pasta de digitações tsconfig.json?

EDIT: abriu um novo problema para rastrear isso: #41425

Com a fusão do #36282, surge um novo problema. Ao usar o superagente em um projeto somente de nó, a introdução da diretiva de barra tripla

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

resulta nas tipagens DOM sendo adicionadas de forma transparente ao projeto. Como este é um projeto somente de nó, no entanto, não há DOM e, portanto, códigos como

window.setTimeout()

deve resultar em um erro TypeScript. Como as tipagens do DOM são incluídas silenciosamente, esse não é o caso e pode levar a bugs sutis na base de código.

Existe uma maneira de incluir digitações somente de nó ou somente de navegador em um projeto, para que possamos escolher qual usar?

Outro efeito colateral de ter uma dependência é dom é que ela impede que supertest ( superagent ) seja usado em um projeto com lib: webworker , ref: https: //github.com/microsoft/TypeScript/issues/20595. Pelo que vejo, isso não foi mencionado antes.

$ npm i @types/ superagent@latest -D

Deve fazer o truque!