Yes, usually. The types option lists which @types packages add globals to your project. Setting it to an explicit list, such as node and your test runner, keeps stray packages from adding global names, and it makes the type environment match what you actually run.
What the option does
The TypeScript tsconfig reference says types limits which @types packages are included in the global scope. Its example, "types": ["node", "jest"], loads only those two. The reference adds two details:
- It does not affect normal imports such as
import * as moment from "moment". It controls globals, such asprocessfrom Node, and auto import suggestions. - The reference says the default is an empty list, and that for versions before TypeScript 6.0 every visible
@typespackage is included by default.
Because the default depends on your compiler version, an upgrade can change which globals exist. Setting the list yourself removes that surprise.
Why it is relevant to hardening
A global type is a name the compiler accepts without an import. If a transitive @types package slips in, code can compile against a global that does not exist in your runtime, such as a browser global in a server build. The result is a runtime failure, or worse, a branch that behaves differently on the server than anyone expected.
There is also a review benefit. An explicit list is a short, visible statement of the environments the project targets. A reviewer can see that a backend service declares node and nothing for the browser.
How to set it
- Look at which
@typespackages are installed:npm ls --alland search for@types/. - Decide which globals your code truly needs. A Node API usually needs node and a test framework.
- Add the list to
compilerOptions:
{
"compilerOptions": {
"strict": true,
"types": ["node"]
}
}
- Run the compiler. Errors tell you which globals were being supplied implicitly, and you can add those packages to the list or import them directly.
- Keep test globals out of your production build by using a second tsconfig for tests that adds the test runner.
A note on dependencies
Type packages are real npm packages and appear in your lockfile and SBOM. They run no code at runtime, but install scripts and ownership changes apply to any package you install, so keep them in the scan scope. Trim ones you do not use.
What it will not do
The option does not stop a package from being installed, and it does not change what Node loads at run time. It only affects what the compiler assumes. Treat it as hygiene, in the same bucket as pinning the package manager.
Safeguard includes @types packages in its dependency inventory and SBOM output, so nothing hides because it is only a type package. Try a free scan.
Quick check
Does the types option block an import of a package?
No. It only limits which type packages add globals, per the TypeScript reference.
What is the default if I do not set it?
The reference says the default is an empty list, and that before TypeScript 6.0 all visible @types packages were included. Check your compiler version.
Sources
Last reviewed: 19 October 2026.
