Definitelytyped: Ошибка @types/superagent TS2304: не удается найти имя «XMLHttpRequest».

Используете ли вы опцию --lib dom для tsc?

Нет, я не знаю. И я не уверен, поможет ли это, но на самом деле моя прямая зависимость — супертест. Я использую его для модульного тестирования серверного кода.

@vvakame — добавление "dom" к моему массиву compilerOptions.lib в tsconfig.json помогло. Это кажется немного нелогичным. Должно ли это быть ожидаемым поведением или это просто временное решение?

отказ от ответственности: я не пользователь суперагента.
Я думаю, что это ожидаемое поведение.

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

элегантный и многофункциональный браузер/узел HTTP с плавным API

работать вокруг.

interface XMLHttpRequest {}

Единственная проблема, с которой я столкнулся при добавлении "dom" к моему tsconfig.json , заключается в том, что в моем файле не было раздела lib , и теперь, когда он у меня есть, мне нужно включить другие библиотеки по умолчанию, такие как "es2016" .

Может быть, есть автоматизированный способ исправить это? который не требует изменения tsconfig.json ?

добавление ["dom", "es2017"] в lib исправило это.

Единственная проблема с добавлением «dom» в мой tsconfig.json заключается в том, что я пишу код на стороне сервера. Поэтому мне не имеет смысла добавлять эту библиотеку. XMLHttpRequest не поставляется с Node.js, а пакет суперагента не выдает ошибок и ошибок в Node.js. Я думаю, проблема в том, что пакет @typings не использует XMLHttpRequest условно. Если пакет хорошо работает на Node.js и в браузере, @typing тоже должен работать.

сегодня тоже столкнулся с этим. Если мы не можем условно предоставить/исключить определенные типы, должны ли мы рассмотреть возможность предоставления двух версий этих типов для использования узла и дома?

Вы можете добавить файл superagent.d.ts со следующим содержимым:

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

@vvakame на самом деле не является «ожидаемым поведением» для библиотеки, разработанной для использования узла или DOM, требующей типизации для обоих в обеих средах. Использование этой библиотеки требует от людей добавления типов, которые могут легко вызвать ошибки, поскольку вы не увидите предупреждений компилятора при доступе к глобальным переменным браузера в node.

Мы тоже были укушены этим в https://github.com/strongloop/loopback-next . При добавлении библиотеки dom глобальное пространство имен внезапно загрязняется типами вроде Request , которых нет в Node.js.

Мы пишем стек HTTP-сервера, поэтому обычно делаем import {ServerRequest as Request} from 'http' . Однако, если эта строка случайно опущена или ServerRequest не имеет псевдонима Request , TypeScript успешно компилирует наш код, и ошибка обнаруживается только во время выполнения. Другими словами, TypeScript больше не может обнаруживать ошибки во время компиляции, что противоречит цели.

Я только начинаю новый проект и подумал, что буду умнее и обойду это, переключившись с супертеста на chai-http, но chai-http использует @types/supertest. -_-

Мы рассмотрим обходной путь: https://github.com/jwalton/node-supertest-fetch

Есть какие-нибудь обновления по этому поводу или исправления не будет? Я думаю, что @zephyrec выразился лучше всего, многие люди используют это для серверной части (т.е. node).

Есть новости по этому поводу?

Простой обходной путь — использовать другую конфигурацию машинописного текста для запуска тестов, которая расширяет ваш оригинал и настраивает его. Итак, вы создаете файл tsconfig.test.json :

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

(в качестве альтернативы вы можете просто установить флаг компилятора skipLibCheck:true вместо настройки библиотек, и это пропустит проверку типов для всех node_modules )

Если вы используете ts-jest , вы можете сказать ему использовать вашу конфигурацию через

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

Таким образом, вы не жертвуете безопасностью типов в своем обычном коде, что определенно не подходит (я бы бросил супертест в одно мгновение, прежде чем делать это).

https://github.com/DefinitelyTyped/DefinitelyTyped/pull/33517 устраняет эту проблему, но этому PR препятствует слияние из-за ошибки

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

Я интерпретирую это как означающее, что @types/superagent не может обновить свое требование TypeScript до 3.0+, пока все пакеты @types , которые зависят от @types/superagent, также не обновят свое требование TypeScript до 3.0+. Мне это кажется недостатком в системе @types , потому что она привязывает мою версию TypeScript к самой старой версии TypeScript из всех вещей, которые зависят от меня.

Может ли кто-нибудь подтвердить мое понимание этого сообщения об ошибке, и если да, то есть ли способ его обойти?

В отсутствие лучшего постоянного исправления, как в этом PR, я решил проблему в своем приложении следующим образом:

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

Эта директива lib с «тройной косой чертой» будет работать в TypeScript версии 3.0+.

С момента открытия этого выпуска прошло почти 2,5 года! Как мы можем это решить.

FWIW, проблема исчезает, когда вы включаете параметр компилятора TypeScript skipLibCheck .

Когда skipLibCheck включен, TypeScript не будет проверять файлы .d.ts — как из таких зависимостей, как @types/superagent , так и любые файлы .d.ts , которые могут быть в вашем проекте. Вы можете удалить dom из своих библиотек, и компилятор больше не будет жаловаться.

В качестве приятного побочного эффекта skipLibCheck обычно значительно увеличивает скорость сборки.

@bajtos Это может привести к ошибкам, поскольку снижает безопасность типов.

• lib: [ "es6" ] сработало
• target: "es2016+" тоже сработало для меня

@ G-Rath Если я не ошибаюсь, skipLibCheck не снижает безопасность типов вашего кода, а только файлов d.ts, большинство из которых, вероятно, являются частью узловых модулей, а не вашего кода в любом случае.

Что касается skipLibCheck, это не жизнеспособный обходной путь IMO. Из https://stackoverflow.com/questions/52311779/usage-of-the-typescript-compiler-argument-skiplibcheck «в зависимости от того, какие были ошибки, компилятор может восстановить их таким образом, что это вызовет проблемы в другом месте кода остаться незамеченным (например, заменив ошибочный тип любым), следовательно, подавление ошибок типа (путем --skipLibCheck, //@ts-ignore или любым другим способом) является рискованной практикой"

@carnesen , вы поспорили на это - это был именно тот вопрос о стеке, который я собирался процитировать :joy:

@rjmunro ну вот 😃

Это не так плохо, как // @ts-ignore , но все, что подавляет ошибки типов, независимо от того, насколько редко, технически ослабляет типобезопасность вашего кода, тем более что ваша папка node_modules состоит из .d.ts Файлы

Я думаю, что самым чистым решением на самом деле является PR #33517 от @carnesen , который добавляет библиотеку dom в качестве внешней ссылки к определению типа superagent , поскольку ссылки на Blob и XMLHttpRequest требуются определениями типа superagent , но не его реализацией, в зависимости от того, как он используется (_browser vs node_).

Единственным реальным недостатком является то, что для ссылки на библиотеку требуется машинописная версия версии 3.0.0, которая была выпущена примерно 9 месяцев назад.
Я не уверен, повлияет ли это только на chai-http (см. Travis-CI ) или есть другие зависимости, для которых потребуется повысить их машинописную версию до 3.0.0.

Любые обновления? Снова через 2 месяца...

После прочтения всего этого самое чистое решение, доступное в настоящее время, принадлежит @carnesen , но у меня не работает :-(

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

Я также проверил его PR (https://github.com/DefinitelyTyped/DefinitelyTyped/pull/33517), но ошибка TravisCI не имеет смысла, потому что chai-http не требует версии TS ниже 3.0...

Я новичок в TypeScript, поэтому, если я делаю что-то не так, дайте мне знать. Я только что отправил точно такой же код, который @carnesen сделал в новом PR, чтобы копнуть глубже в журналах Travis CI (https://github.com/DefinitelyTyped/DefinitelyTyped/pull/36282)

РЕДАКТИРОВАТЬ:

кажется, что chai-http больше не проблема, а promisify-supertest ... это похоже на не очень популярный заброшенный пакет (https://github.com/ariporad/promisify-supertest/blob /мастер/тест/index.js)

Каков процесс обновления этого?

РЕДАКТИРОВАТЬ 2:

Я копнул глубже и обнаружил, что необходимо обновить следующие определения типов:

• обещание-супертест
• простой cw-узел
• суперагент-баньян
• суперагент без кеша
• суперагент-префикс
• супертест

// ошибка TS2304: не удается найти имя «XMLHttpRequest»
объявить интерфейс XMLHttpRequest {}
// ошибка TS2304: не удается найти имя "большой двоичный объект"
объявить интерфейс Blob {}

@JasonKleban , куда идет этот файл? В node_modules > superagent ? Я пытался понять это, и я в своем уме.

@mkeyamato - я не могу вспомнить, где я успешно его использовал, но не в node_modules, поскольку вы сами не управляете этими файлами. Вместо этого он, вероятно, просто рядом с другими вашими исходными файлами. Вы бы попробовали это первым, я полагаю. Без изменений?

Вы также можете поэкспериментировать с настройкой папки tsconfig.json typings?

РЕДАКТИРОВАТЬ: открыл новую проблему, чтобы отслеживать это: # 41425

С объединением #36282 возникла новая проблема. При использовании суперагента в проекте, состоящем только из узлов, введение директивы тройной косой черты

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

приводит к тому, что типы DOM прозрачно добавляются в проект. Однако, поскольку это проект только для узлов, в нем нет DOM, поэтому такой код, как

window.setTimeout()

должно привести к ошибке TypeScript. Поскольку типы DOM включаются автоматически, это не так, и это может привести к тонким ошибкам в кодовой базе.

Есть ли способ, которым мы можем включить типизацию только для узла или только для браузера в проект, чтобы мы могли выбирать, что использовать?

Еще один побочный эффект наличия зависимости dom заключается в том, что она предотвращает использование supertest ( superagent ) в проекте с lib: webworker , ссылка: https: //github.com/microsoft/TypeScript/issues/20595. Насколько я вижу, об этом раньше не упоминалось.

$ npm i @types/ superagent@latest -D

Должен сделать трюк!