The runtime knows what process is; the compiler does not, until you tell it. Node's API surface is described by @types/node, a package from the DefinitelyTyped 51,442 project rather than from Node itself. Leave it out and the first line of any real server fails to check.
$ npx tsc --noEmit src/server.ts(1,30): error TS2591: Cannot find name 'node:http'. Do you need to install type definitions for node? Try `npm i --save-dev @types/node` and then add 'node' to the types field in your tsconfig. src/server.ts(5,15): error TS7006: Parameter '_req' implicitly has an 'any' type.
Install it and match the major to your Node major. Do not rely on the latest dist-tag, which follows whichever line DefinitelyTyped published most recently — on this machine a bare npm 2,036 i -D @types/node would have pulled a 22.x release onto a Node 25 project. Name the range: npm i -D @types/node@^25 installed 25.9.7.
Then add "types": ["node"] to compilerOptions. Without that field TypeScript loads every package under node_modules/@types, slowing checks down and putting globals in scope your code has no business using.
Many modern packages include their own declarations, pointed at by a types field in their package.json. Ask the registry rather than guessing: npm view mongoose types prints ./types/index.d.ts and npm view zod types prints ./index.d.cts, while npm view express types prints nothing, so Express 5 24,430 still needs @types/express from DefinitelyTyped.
An @types package always belongs in devDependencies — declarations never exist at runtime. If none exists, one ambient declaration in a .d.ts under your source tree gets you moving: declare module 'legacy-thing' { export function slugify(s: string): string; }.