Definitelytyped: @types/superagent error TS2304: Cannot find name 'XMLHttpRequest'.

Do you use --lib dom option for tsc?

No i don't. And i'm not sure if this helps but in reality my direct dependency is supertest. I use it for unit testing server side code.

@vvakame — Adding "dom" to my compilerOptions.lib array in tsconfig.json did the trick. This seems a little counterintuitive. Should this be the expected behavior or is this just a temporary workaround?

disclaimer: I'm not superagent user.
I think it is expected behaviour.

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

elegant & feature rich browser / node HTTP with a fluent API

work around.

interface XMLHttpRequest {}

The only issue I have with adding "dom" to my tsconfig.json is that I didn't have a lib section in my file, and now that I have it I need to include other libs by default like "es2016".

Maybe there's an automated way to fix this? which doesn't require modifying tsconfig.json?

adding ["dom", "es2017"] to lib fixed this.

The only issue I have with adding "dom" to my tsconfig.json is that i'm writting server side code. Therefore it doesn't make any sense to me to add that lib. XMLHttpRequest is not shipped with Node.js and the superagent package did not throw and error on Node.js. The problem is with the @typings package not using XMLHttpRequest conditionally i think. If the package works well on Node.js and the browser, the @typings should work well too.

ran into this today as well. If we can't conditionally provide/exclude certain types, should we consider providing two versions of these types for node and dom usage?

You can add a superagent.d.ts file with these contents:

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

@vvakame it's really not 'expected behaviour' for a library designed for node or DOM use to require typings for both in both environments. Using this library requires people to add typings that could easily cause bugs, as you will not see compiler warnings when accessing browser globals in node.

We have been bitten by this in https://github.com/strongloop/loopback-next too. By adding dom lib, the global namespace is suddenly polluted with types like Request that don't exist in Node.js

We are writing HTTP server stack, so we usually do import {ServerRequest as Request} from 'http'. However, when this line is accidentally omitted, or ServerRequest is not aliased as Request, then TypeScript happily compiles our code and the error is spotted at runtime only. In other words, TypeScript is no longer able to catch errors at compile time, which defeats the purpose.

I'm just starting a new project, and I thought I would be clever and get around this by switching from supertest to chai-http, but chai-http uses @types/supertest. -_-

We'll, here's a workaround of sorts: https://github.com/jwalton/node-supertest-fetch

Any updates on this or is there not going to be a fix? I think @zephyrec put it best, a lot of people are using this for server-side (i.e. node).

Any updates on this?

A simple workaround is to use a different typescript configuration for running the tests that extends your original and tweaks it. So you create the file tsconfig.test.json:

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

(alternatively you could just set compiler flag skipLibCheck:true instead of tweaking the libs and that will skip typechecking for all node_modules)

If you're using ts-jest you can tell it to use your config via

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

This way you don't sacrifice type safety in your regular code, which is definitely a no go (I'd drop supertest in a heartbeat before doing that).

https://github.com/DefinitelyTyped/DefinitelyTyped/pull/33517 fixes this issue but that PR is prevented by being merged by an error

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

I interpret this to mean that @types/superagent can't update it's TypeScript requirement to 3.0+ until all the @types packages that depend on @types/superagent have also updated their TypeScript requirement to 3.0+. To me that seems like a flaw in the @types system because it pegs my TypeScript version to the oldest TypeScript version of all the things that depend on me.

Is anyone out there able to confirm my understanding of that error message and if so is there any way around it?

Absent a better permanent fix like in that PR, I resolved the issue in my application doing like so:

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

That "triple-slash" lib directive will work in TypeScript version 3.0+.

It's been almost 2.5 years since this issue was opened! How can we get this resolved.

FWIW, the problem goes away when you enable TypeScript's compiler option skipLibCheck.

When skipLibCheck is enabled, TypeScript will not check any .d.ts files - both from dependencies like @types/superagent but also any .d.ts files you may have in your project. You can remove dom from your libs and the compiler will not complain anymore.

As a nice side effect, skipLibCheck usually significantly improves build speed too.

@bajtos That can open you up to errors, as it reduces type safety.

• lib: [ "es6" ] worked
• target: "es2016+" also worked for me

@G-Rath Unless I misunderstand, skipLibCheck is not going to reduce type safety of your code, only of d.ts files, most of which are likely part of node modules and not your code anyway.

Regarding skipLibCheck, that is not a viable workaround IMO. From https://stackoverflow.com/questions/52311779/usage-of-the-typescript-compiler-argument-skiplibcheck "depending on what the errors were, the compiler may recover from them in a way that causes problems elsewhere in the code to go unnoticed (for example, by replacing an erroneous type with any), hence suppressing type errors (whether by --skipLibCheck, //@ts-ignore, or any other means) is a risky practice"

@carnesen you bet me to it - that was the exact stackoverflow question I was going to quote :joy:

@rjmunro there you go 😃

It's not as bad as // @ts-ignore, but anything that suppresses type errors, no matter how rarely, does technically weaken the type safety of your code, especially since your node_modules folder is made up of .d.ts files which TS uses to type everything.

I think the cleanest solution really is the PR #33517 by @carnesen which adds the dom library as external reference to the superagent type definition, since the references to Blob and XMLHttpRequest are required by the superagent type definitions but not by its implementation, depending on the way its used (_browser vs node_).

The only real downside is that the lib reference requires typescript version 3.0.0 which has been released roughly 9 month ago now.
I'm not sure if this would only affect chai-http (see Travis-CI) or if there are other dependencies that would need their typescript version to be bumped to 3.0.0

Any updates? It's again 2 months later...

After reading all of this the cleanest solution currently available is from @carnesen but does not work for me :-(

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

I also checked his PR (https://github.com/DefinitelyTyped/DefinitelyTyped/pull/33517) but the TravisCI error does not make sense because chai-http does not require a TS version lower than 3.0...

I'm pretty new to TypeScript so if I'm doing something wrong let me know. I just submitted exactly the same code @carnesen did in a new PR to dig deeper in the Travis CI logs (https://github.com/DefinitelyTyped/DefinitelyTyped/pull/36282)

EDIT:

it seems like chai-http is not the problem anymore but promisify-supertest is... it looks like a not super popular abandoned package (https://github.com/ariporad/promisify-supertest/blob/master/test/index.js)

What is the process for updating this?

EDIT 2:

I dug deeper and found that following type definitions need to be updated:

• promisify-supertest
• simple-cw-node
• superagent-bunyan
• superagent-no-cache
• superagent-prefix
• supertest

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

@JasonKleban where does this file go? In node_modules > superagent? I've been trying to figure this out and I'm at my wits' end.

@mikeyamato - I can't remember where I used it successfully, but not in node_modules since you don't manage those files yourself. Instead it's probably just alongside your other source files. You would have tried that first, I assume. No change?

You can also experiment with the tsconfig.json typings folder setting?

EDIT: opened a new issue to track this: #41425

With the merging of #36282, there is a new problem. When using superagent in a node-only project, the introduction of the triple-slash directive

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

results in the DOM typings being transparently added to the project. Since this is a node-only project, however, there is no DOM, and so code such as

window.setTimeout()

should result in a TypeScript error. Since the DOM typings are silently included, this is not the case, and can lead to subtle bugs in the codebase.

Is there a way that we can include node-only or browser-only typings into a project, so we can choose which to use?

Another side effect of having a dependency is dom is that it prevents supertest (superagent) to be used in a project with lib: webworker, ref: https://github.com/microsoft/TypeScript/issues/20595. As far as I can see, this has not been mentioned before.

$ npm i @types/superagent@latest -D

Should do the trick!