@types/jest Explained: What It Is and How to Use It Safely

@types/jest is the package that provides TypeScript type definitions for the Jest testing framework, and it ships from the DefinitelyTyped project rather than from the Jest team itself. If you write tests in TypeScript and call describe, it, expect, or jest.fn(), the type checker needs to know the shapes of those globals. That is exactly what @types/jest supplies. It contains no runtime code, only .d.ts declaration files.

Understanding where this package comes from and how it is installed matters more than it first appears, because anything in your dependency tree, even a types-only package, is code your build environment trusts.

What @types/jest actually contains

The @types/jest package is a bundle of TypeScript declaration files. Open the installed folder under node_modules/@types/jest and you will find index.d.ts and supporting files describing the Jest API surface: the global test functions, the expect matchers, mock utilities, timer controls, and configuration types.

None of this executes at runtime. Declaration files are erased during compilation. Their only job is to let tsc and your editor understand and check the Jest calls you write. That is why the package belongs in devDependencies rather than dependencies.

A typical install looks like this:

npm install --save-dev @types/jest jest ts-jest typescript

And a minimal package.json snippet:

{
  "devDependencies": {
    "@types/jest": "^29.5.0",
    "jest": "^29.7.0",
    "ts-jest": "^29.1.0",
    "typescript": "^5.4.0"
  }
}

Where the types-jest definitions come from

The @types/jest definitions live in the DefinitelyTyped repository, a community-maintained monorepo of type definitions for packages that do not ship their own. Contributors submit pull requests, maintainers review them, and a publishing bot pushes each accepted change to the @types scope on npm.

This is an important distinction. When you install Jest, you get code authored and released by the Jest maintainers. When you install the types-jest package, you get definitions authored by DefinitelyTyped contributors, who may or may not be the same people. The definitions track the real Jest API closely, but they are a separate release train with a separate set of maintainers.

Match the version to your Jest version

The most common practical problem with @types/jest is version drift. The types package is versioned to loosely follow the major and minor of Jest itself. If you upgrade Jest to a new major version but leave the types pinned to an old one, the compiler will flag calls that are valid at runtime, or worse, accept calls that will fail.

Keep the first two version segments aligned. If you run Jest 29, install @types/jest in the 29 range. Newer Jest releases increasingly ship their own types through @jest/globals, so on the latest versions you may not need the separate types package at all:

import { describe, it, expect } from '@jest/globals';

If you import globals this way, you can often drop @types/jest entirely, which removes one third-party dependency from your tree. Fewer dependencies means fewer things to audit.

The security angle most teams miss

A types-only package feels harmless. It has no runtime footprint, so how could it hurt you? The risk is not in what the published .d.ts files do. It is in the install itself.

Every npm install runs in an environment with network access, filesystem access, and often credentials. Any package in the tree can define install lifecycle scripts, and a malicious release, or a compromised maintainer account, could ship a version that runs code during installation. This is the classic supply chain attack pattern, and it applies to devDependencies just as much as to production dependencies, because your CI runners and developer laptops install both.

The @types scope has a relatively good track record, and the DefinitelyTyped publishing pipeline adds review friction. But "relatively good" is not "immune." Treat type packages as part of your attack surface:

• Pin versions with a committed lockfile so a compromised patch release cannot slip in silently on the next npm ci.
• Watch for typosquats. @types/jest is correct; a package named types-jest (no scope, no slash) or @type/jest (missing the plural) is a red flag worth investigating before install.
• Run software composition analysis across your dev tree, not just production. An SCA tool can flag a known-bad version of any transitive package, including type definitions.

For a broader treatment of how a single manifest entry pulls in dozens of trusted-by-default packages, see what is a dependency in programming.

A safe setup checklist

Before you commit a Jest and TypeScript setup, run through this:

1. Confirm the package name is exactly @types/jest, scope and all.
2. Align the major version with your installed Jest.
3. Keep it in devDependencies, never dependencies.
4. Commit package-lock.json (or your equivalent lockfile) and install with npm ci in CI.
5. Consider dropping the package in favor of @jest/globals imports if your Jest version supports them.
6. Include dev dependencies in whatever vulnerability scan you run on the repository.

FAQ

Do I still need @types/jest with modern Jest?

Not always. Recent Jest versions expose typed globals through @jest/globals, which you can import directly. If you adopt those imports, you can frequently remove the separate @types/jest dependency. On older setups, or when relying on ambient globals, you still need it.

Should @types/jest be a dependency or a devDependency?

A devDependency. It contains only type declarations used at compile time and in your editor. It has no place in a production dependency list because it contributes nothing at runtime.

Is @types/jest maintained by the Jest team?

No. It is maintained by contributors to the DefinitelyTyped project and published to the @types scope by an automated bot. Jest's own maintainers publish Jest, while the type definitions are a community effort tracking that API.

Can a types-only package be a security risk?

Yes, indirectly. The published declarations do not run at runtime, but the install process for any package can execute lifecycle scripts, and a compromised or typosquatted release could carry malicious code. Pin versions, use a lockfile, and scan dev dependencies too.