Fix Cannot find name 'AbortSignal' in axios typings

TL;DR#

The axios type declarations mention the global AbortSignal type. In a Node or browser project, TypeScript only has that name if your compilation includes the DOM lib or an @types/node release that declares it. A Node project with "lib": ["es2018"] and an old @types/node has neither, so npm run build fails inside node_modules/axios/index.d.ts. For a Node backend, install @types/node for your Node major and, on TypeScript 6 or later, add "types": ["node"]. For browser code, add "DOM" to lib. Upgrading axios alone stopped working as a fix after axios 1.9.

The error#

This is the output from the Stack Overflow question behind this page. The asker's build of a Node TypeScript project started failing as soon as axios was added:

node_modules/axios/index.d.ts:93:12 - error TS2304: Cannot find name 'AbortSignal'.
 
93   signal?: AbortSignal;
              ~~~~~~~~~~~
 
Found 1 error.

That is the pretty format tsc prints in a terminal. Run through a pipe or a CI log, the same error appears as a single line. Here it is from a reproduction with axios 0.24.0, TypeScript 4.5.2 and @types/node 14.17.34 in the official node:22-alpine Docker image (13 October 2026). The project has one source file that calls axios.get:

> abortsignal-repro@1.0.0 build
> tsc
node_modules/axios/index.d.ts(93,12): error TS2304: Cannot find name 'AbortSignal'.
exit=2

The exit= lines in these blocks are the reproduction script echoing the exit code; they are not npm output. Your own code is fine. The compiler is failing while it checks a declaration file that ships inside the axios package.

Why the axios typings need a global you do not have#

Line 93 of the axios 0.24.0 typings is signal?: AbortSignal;. The file uses AbortSignal as an ambient global type and never declares it. It relies on the consuming project to provide one. In a Node or browser project, TypeScript can get it from two places (the WebWorker lib declares it too, for worker code):

• The DOM lib. The lib reference says the default set covers built-in JavaScript APIs as well as "type definitions for things found in browser environments". As soon as you write an explicit "lib": ["es2018"], you replace that default with ECMAScript-only declarations, and the browser globals disappear.
• @types/node. The Node 14 globals documentation marks AbortController as an experimental global on that line, enabled with a command-line flag. The Node 14 typings did not declare it or AbortSignal until DefinitelyTyped PR #58270, merged on 19 January 2022. In the reproduction, @types/node 14.18.8 still has no AbortSignal in globals.d.ts, and 14.18.9 declares it (interface AbortSignal and declare var AbortSignal).

The question does not show the asker's tsconfig, but the accepted answer's snippet, which the asker accepted, starts from an ES-only lib (es2018). With that lib and an @types/node older than that change, or none at all, no file in the compilation declares the name. Removing @types/node entirely gives the same error, which confirms that it was never providing the type:

> abortsignal-repro@1.0.0 build
> tsc
node_modules/axios/index.d.ts(93,12): error TS2304: Cannot find name 'AbortSignal'.
exit=2

The problem was reported to axios in issue #4304. One of the answers on the question points to the axios side of the fix, PR #4229. It replaced the global with an axios-owned interface and was merged in May 2022. The GitHub compare between the v0.27.2 and v1.0.0 tags contains that merge commit, so 1.0.0 was the first release with it.

Which axios releases trigger it#

The answers on Stack Overflow date from the 0.2x era, and since then the axios typings have changed several times. The same project (TypeScript 4.5.2, @types/node 14.17.34, "lib": ["es2018"]) was built against a range of axios releases. Only the axios version changed between runs:

Two typings changes explain the later rows. PR #6867 typed fetchOptions with the fetch API's RequestInit (first in v1.10.0). PR #10959 added toAbortSignal(): AbortSignal; to the CancelToken interface (first in v1.18.1). With axios 1.20.0 on the old stack, the last line of the output is the original error:

node_modules/axios/index.d.ts(472,23): error TS2304: Cannot find name 'RequestInit'.
node_modules/axios/index.d.ts(605,20): error TS2304: Cannot find name 'AbortSignal'.
exit=2

So "upgrade axios" was a real fix in 2022 and is not one now. Updating @types/node within the 14.x line, the fix suggested on Stack Overflow, also falls short today. Using axios 1.20.0 with @types/node 14.18.9 clears AbortSignal, but 14 errors about URL, Request, RequestInit and the other fetch types remain.

Fix#

Choose the fix that matches where the code runs.

1. Node backend: load Node's own types. Install the @types/node major that matches your Node runtime. The reproduction used Node 22, so:

npm install --save-dev @types/node@22

Recent @types/node releases also need a recent compiler. The npm registry entry for @types/node tags 20.10.0 as the last release for TypeScript 4.5. If you are still on the asker's 2021 stack (TypeScript 4.5, Node 14), stay on the 14.x line: in the reproduction, 14.18.9 was enough to clear the AbortSignal error with axios 0.24.0.

2. On TypeScript 6 or later, list node in types. The types reference now says that by default it is set to an empty list, and that every visible @types package is loaded only on versions below TypeScript 6.0. For a package left out of types, the first effect the doc lists is that it "Will not add globals to your project". On TypeScript 7.0.2 with @types/node 22.20.5 installed but no types field, axios 1.20.0 still fails with all 15 errors. A complete tsconfig.json that builds:

{
  "compilerOptions": {
    "target": "es2022",
    "module": "nodenext",
    "lib": ["es2022"],
    "strict": true,
    "rootDir": "src",
    "outDir": "dist",
    "types": ["node"]
  },
  "include": ["src"]
}

The page on Cannot find name 'console' covers the same types default in more depth. It is the same mechanism: a Node global goes missing because @types/node was never loaded.

3. Code that runs in a browser: add DOM to lib. This is the fix from the accepted Stack Overflow answer, and it made both stacks in the reproduction build (axios 0.24.0 on TypeScript 4.5.2, axios 1.20.0 on TypeScript 7.0.2):

{
  "compilerOptions": {
    "target": "es2018",
    "module": "commonjs",
    "lib": ["es2018", "DOM"],
    "strict": true,
    "outDir": "dist"
  },
  "include": ["src"]
}

The same lib also declares browser globals such as window and document, which the lib reference lists as its contents and which do not exist in Node. In a backend, code that uses them type-checks and then throws at runtime, which is why step 1 is the better fix for server code.

4. Last resort: skipLibCheck. Setting "skipLibCheck": true made both the 2021 stack and the current one build. The option's reference defines it as "Skip type checking of declaration files." It applies to every package, not only axios. If you already use it for other reasons, see how skipLibCheck stops tsc from checking dependencies. Otherwise, load the missing types instead of switching the check off.

Verify the fix#

Run the build the same way your CI does. npm run build runs the project's local tsc, which is the version that matters here. If a bare tsc is not found on Windows, the page on running the local compiler through npm explains why. A passing build prints only the script header:

> abortsignal-today@1.0.0 build
> tsc
exit=0

That run used axios 1.20.0, TypeScript 7.0.2 and @types/node 22.20.5. Compared with the failing run before it, the only change was the types line. Check the versions you actually resolved, because a lockfile can hold an older axios than your package.json range suggests:

npm ls axios typescript @types/node

When the error comes back after a TypeScript upgrade#

A project that built on TypeScript 5.x can hit this error again after moving to 6.0 or 7.0 without touching axios. In the reproduction, the same tsconfig with @types/node installed and no types field built cleanly on TypeScript 5.9.3 and failed on 7.0.2. Version 5.9 picks up @types/node automatically, and 6.0 and later do not. The fix is step 2 above. The TypeScript 6 migration notes for Next.js and Supabase list the other breaking changes in that release.

The next error after the upgrade can be one that is not about types at all. TypeScript 7.0.2 refused the reproduction's first tsconfig, which had outDir but no rootDir, before checking any file:

tsconfig.json(7,5): error TS5011: The common source directory of 'tsconfig.json' is './src'. The 'rootDir' setting must be explicitly set to this or another path to adjust your output's file layout.
  Visit https://aka.ms/ts6 for migration information.

Setting "rootDir": "src", as in the tsconfig above, cleared it.

The error points at a file in node_modules, but the problem is in your tsconfig: it does not declare the environment axios is written for. For a Node service, @types/node for your runtime and an explicit types list fixed it on axios 1.20.0, the current release, where the older fixes no longer reach. For a browser bundle, DOM belongs in lib anyway. Pinning an old axios, or switching on skipLibCheck across every dependency, only puts off the next release of the typings.

Further reading: Fix tsc SyntaxError: Unexpected token '?' on old Node.js. Also see Fix Vitest: Cannot find namespace vi in TypeScript.