The Jest latest version is in the 30.x line (30.4.2 at the time of writing), and the strongest security reason to stay current is not a headline CVE in Jest itself but the large transitive dependency tree that older Jest majors carry into your dev environment. Jest is a devDependency, so it never ships to production, yet it installs a substantial set of packages that run with your CI and developer-machine privileges. Reducing and refreshing that tree is the real payoff of upgrading.
Jest 30 was a significant modernization over the long-lived 29 line, dropping support for very old Node versions and pruning internal dependencies. If your project is still on 27 or 28, you are running test tooling built on a materially older set of transitive packages.
Why an old test runner is a supply chain concern
Every package under node_modules — dev or not — is code that executes during npm install, jest, and your CI pipeline. That pipeline typically holds registry tokens and cloud credentials. So the size and freshness of your dev dependency tree is a legitimate attack-surface question, not just a housekeeping one.
Older Jest majors depend on older versions of packages like micromatch, braces, and various transform and transitive utilities. When one of those deep dependencies gets an advisory, a modern Jest usually already resolves to the patched version, while a pinned old Jest holds you on the vulnerable one until you either upgrade or fight with overrides. Staying near the latest version means most transitive advisories are already fixed for you.
Check what you are on and what is current
# What your project resolves today
npx jest --version
# What the registry considers latest
npm view jest version
# See the whole installed Jest-related tree
npm ls jest
If npm view jest version reports a 30.x release and your project shows a 27 or 28, that gap is your upgrade backlog. Do not chase the absolute newest patch blindly, but do not sit two majors behind either.
Upgrading across a major, without a broken suite
Jumping a major version of Jest touches config and sometimes matcher behavior, so treat it as a small project rather than a one-line bump.
# Update Jest and its common companions together
npm install --save-dev jest@latest jest-environment-jsdom@latest
# If you use TypeScript via ts-jest, bump it to a matching line
npm install --save-dev ts-jest@latest
Two things routinely break on the way to Jest 30:
- The default test environment. Since Jest 28,
jsdomis no longer bundled by default; you installjest-environment-jsdomand settestEnvironment: 'jsdom'explicitly. Node-only projects can stay on the defaultnodeenvironment and skip it. - Fake timers and snapshot format. Modern timer APIs and snapshot serialization changed across majors. Expect to re-record some snapshots and adjust timer usage. Run the suite, review the snapshot diffs deliberately, and commit them as an intentional change.
Do the upgrade on a branch, run the full suite, and read the changelog for the majors you are crossing rather than assuming a clean bump.
Verify integrity, not just version numbers
When you bump any dev tool, install from the lockfile so the resolved versions and their integrity hashes are what actually land:
npm ci
npm ci refuses to proceed if package.json and the lockfile disagree, which prevents a surprise version from slipping in during the upgrade. Pair it with a review of the lockfile diff so you can see exactly which transitive packages changed underneath Jest — a major bump often moves dozens of them at once.
Keep it current after the upgrade
The one-time upgrade is the hard part; staying current is cheap if you automate it:
- Let a bot open dependency-bump PRs for Jest and its companions, and let CI run the suite against them.
- Run continuous SCA across your full lockfile — devDependencies included — so a new advisory anywhere in the Jest tree surfaces without a manual audit. An SCA tool such as Safeguard treats dev and runtime dependencies as one graph, which is the right model here. The trade-offs between tooling options are laid out on our pricing page.
- Re-run
npm ls jestafter big installs to catch duplicate Jest versions sneaking in through a mismatched transitive dependency.
The goal is not to always be on the day-one latest patch, but to never be so far behind that a routine advisory turns into a multi-day override exercise.
FAQ
What is the Jest latest version?
Jest is on the 30.x line, with 30.4.2 as the latest release at the time of writing. Check npm view jest version for the current published value, since patch releases ship regularly.
Is it a security problem to run an old version of Jest?
Indirectly, yes. Jest is a dev dependency, but old majors pull in older transitive packages that run with your CI and developer privileges. When those deep dependencies get advisories, a current Jest usually already resolves the fix while an old one holds you on the vulnerable version.
How do I upgrade Jest across a major version?
Bump Jest and its companions (jest-environment-jsdom, ts-jest) together on a branch, install jsdom explicitly if your tests need a browser-like environment, re-record changed snapshots deliberately, and run the full suite before merging. Read the changelog for each major you cross.
Does Jest ship to production?
No. Jest is a testing tool used only in development and CI. The security relevance is the code that runs at build and test time, not your production bundle.