← ./articles

VS Code Says Cannot Find setTimeout but tsc Passes: Add types node

typescriptvscodenodejstsconfigdebugging

Sometimes TypeScript behaves differently in VS Code and in the terminal.

The terminal passes:

npx tsc --noEmit

But VS Code still underlines Node globals:

Cannot find name 'setTimeout'
Cannot find name 'process'
Cannot find name 'Buffer'

If @types/node is already installed, the fix may be to make Node types explicit in tsconfig.json.

Why this happens

The TypeScript CLI and the VS Code TypeScript language server do not always initialize type resolution in the same way.

In Node projects using settings such as module: "Node16", the CLI may resolve @types/node successfully. The language server can still miss those globals if the project does not explicitly list Node types.

That leaves you with a frustrating split:

tsc: passes
VS Code: red squiggles

The fix

Add types: ["node"]:

{
  "compilerOptions": {
    "module": "Node16",
    "target": "ES2022",
    "lib": ["ES2022"],
    "types": ["node"]
  }
}

Then reload the TypeScript project in VS Code:

Ctrl+Shift+P -> TypeScript: Reload Projects

Do not blindly add DOM

If the code runs in Node.js, avoid fixing the problem by adding browser libraries:

{
  "lib": ["ES2022", "DOM"]
}

That may silence some errors, but it also adds browser globals that do not exist at runtime in Node.

Use:

{
  "lib": ["ES2022"],
  "types": ["node"]
}

for Node-only code.

Checklist

When VS Code and tsc disagree:

  • confirm @types/node is installed
  • add "types": ["node"]
  • keep lib aligned with the runtime
  • reload VS Code TypeScript projects
  • run npx tsc --noEmit again

Summary

If VS Code reports missing Node globals but tsc passes, make Node types explicit.

The goal is not to satisfy only the CLI. The editor language server must read the same runtime assumptions as your build.

References