-
-
Notifications
You must be signed in to change notification settings - Fork 6.6k
docs: add blog post for jest 30 (#15556) #15650
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
✅ Deploy Preview for jestjs ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
9dec7f8
to
f6c1ebd
Compare
How much of this did you write by hand vs. an llm? |
f6c1ebd
to
02d3487
Compare
I use a language model for 70% of the work, and I handle the remaining 30% manually. Sometimes the model misinterprets the intended changes, so I review and correct them. Additionally, I add code previews and links to relevant documentation to enhance clarity and usability. Tomorrow, I'll examine it with a fresh head to address any remaining issues. |
02d3487
to
53fbbc3
Compare
website/blog/2025-06-04-jest-30.md
Outdated
|
||
ESM support isn’t just about file extensions. **Under the hood, Jest’s packages now provide proper ESM exports** and have been restructured for better ESM compatibility. All of Jest’s internal modules are bundled into a few files for faster startup, and each official package defines an export map for Node’s ESM resolver. For the average user, this change is invisible – you continue to use Jest the same way – but it generally improves performance by reducing the file I/O overhead on startup. (One side effect: if you were importing internal, unofficial modules from Jest’s code, those imports will break due to the repackaging – but doing that was never supported, so it won’t affect normal usage.) | ||
|
||
On a related note, **Jest 30’s module resolution got smarter for Node ESM features**. You can now use `import.meta` properties in your tests and modules when running under Jest. Specifically, Jest 30 supports `import.meta.url`, `import.meta.filename`, `import.meta.dirname`, and even the new `import.meta.resolve` for module resolution. If you have tests or library code that rely on these ESM-specific globals (for example, determining the current file path via `import.meta.url`), Jest will no longer choke on them – it handles these as Node does (note that some of these features require Node 20+). Additionally, Jest’s resolver now understands `file://` URL imports, which can appear in ESM contexts. Jest now also respects Node’s conditional exports when resolving stub modules (like manual mocks), passing along the `conditions` option. This ensures even stubbed modules pick the correct export variant for the current environment. All of this means Jest 30 plays more nicely with modern ESM projects. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we mention https://github.com/unrs/unrs-resolver in favor of #15619?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand what it is. Add a change suggestion.
website/blog/2025-06-04-jest-30.md
Outdated
| **Server tests** | ~1350s / 7.8 GB max | ~850s / 1.8 GB max | | ||
| **Client tests** | ~49s / 1.0 GB max | ~44s / 0.8 GB max | | ||
|
||
These improvements come from Jest 30’s work on memory leaks, module loading efficiency, and better ESM handling under the hood. While your mileage may vary, many projects – especially large ones – should see Jest 30 running tests a bit faster and using less memory than before. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me know if you'd like some more data for this section. I am close to having a fully passing test run for our tests at Happo and I'd be happy to share some performance numbers for this post.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think any data is appreciate
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here are some numbers for running Jest v29 vs v30 on our main tests at Happo.
206 suites with 1804 tests total
- Local: 2024 MacBook Air M3
- CI: CircleCI medium resource class (2 vCPUs, 4GB RAM), using
--runInBand
)
For the CI times, I only counted the time spent in the step that runs Jest, and not all of the setup and teardown.
Jest Version | Local Time / Max Heap | CI Time (Total of 6 Shards) |
---|---|---|
Jest 29 | 1m 31s / 450 MiB | 11m 5s |
Jest 30 with globalsCleanupMode default setting |
1m 42s / 328 MiB | 9m 31s |
Jest 30 with globalsCleanupMode: 'hard' |
1m 43s / 315 MiB | 9m 47s |
Here are some charts that CircleCI generates of resource usage over the job run. Note that while these jobs are for Jest only, these charts include the setup steps so to understand what it looks like for Jest running, pay most attention to the last couple of minutes of the run or so.
Jest 29:

Jest 30 with globalsCleanupMode
default setting:

Jest 30 with globalsCleanupMode: 'hard'
:

There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I should also mention that I landed all of the fixes that I needed to do before updating to Jest 30, mostly around fixing open handles. Those seemed to have a bigger impact on performance.
On Jest 29 before I landed these fixes, Jest in CI ran in 14m 26s (divided among 6 shards). Here's the resource graph for that:

website/blog/2025-06-04-jest-30.md
Outdated
|
||
### `testPathPattern` is now `testPathPatterns` | ||
|
||
You’ll need to update your config and any CLI usage. In config files, `testPathPatterns` now expects an array of patterns (instead of a single regex). This actually makes the feature more flexible – you can specify multiple include patterns for test files. Correspondingly, the CLI flag is now `--testPathPatterns` (with an “s”). You can provide multiple patterns separated by spaces or by using the flag multiple times. This change shouldn’t affect you unless you were filtering tests by path, but it’s an easy find-and-replace if so. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should probably be more explicit about changing testPathPattern
to testPathPatterns
and maybe offer some before and after examples for extra clarity.
I'll take a pass on the blog post soon, until then I suggest holding off on reviewing beyond mentioning what else needs to be mentioned. |
53fbbc3
to
8cf7413
Compare
website/blog/2025-06-04-jest-30.md
Outdated
|
||
### `testPathPattern` is now `testPathPatterns` | ||
|
||
You’ll need to update your config and any CLI usage. In config files, `testPathPatterns` now expects an array of patterns (instead of a single regex). This actually makes the feature more flexible – you can specify multiple include patterns for test files. Correspondingly, the CLI flag is now `--testPathPatterns` (with an “s”). You can provide multiple patterns separated by spaces or by using the flag multiple times. This change shouldn’t affect you unless you were filtering tests by path, but it’s an easy find-and-replace if so. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This mentions config files but it turns out it is cli only
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It changes in config too. See #12519 (packages/jest-types/src/Config.ts)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does not seem to work via config either as testPathPattern
in Jest 29, or as testPathPatterns
in Jest 30. See:
8cf7413
to
600e055
Compare
babel-jest
babel-plugin-jest-hoist
babel-preset-jest
create-jest
@jest/diff-sequences
expect
@jest/expect-utils
jest
jest-changed-files
jest-circus
jest-cli
jest-config
@jest/console
@jest/core
@jest/create-cache-key-function
jest-diff
jest-docblock
jest-each
@jest/environment
jest-environment-jsdom
@jest/environment-jsdom-abstract
jest-environment-node
@jest/expect
@jest/fake-timers
@jest/get-type
@jest/globals
jest-haste-map
jest-jasmine2
jest-leak-detector
jest-matcher-utils
jest-message-util
jest-mock
@jest/pattern
jest-phabricator
jest-regex-util
jest-repl
@jest/reporters
jest-resolve
jest-resolve-dependencies
jest-runner
jest-runtime
@jest/schemas
jest-snapshot
@jest/snapshot-utils
@jest/source-map
@jest/test-result
@jest/test-sequencer
@jest/transform
@jest/types
jest-util
jest-validate
jest-watcher
jest-worker
pretty-format
commit: |
eaf0347
to
e25edb6
Compare
I updated the blog post. Thanks to @MillerSvt for the outline, it was really helpful! Would you all be able to give this a look? Preview: https://deploy-preview-15650--jestjs.netlify.app/blog/2025/06/04/jest-30 |
| **Server tests** | ~1350s / 7.8 GB max | **~850s / 1.8 GB max** | | ||
| **Client tests** | ~49s / 1.0 GB max | **~44s / 0.8 GB max** | | ||
|
||
Jest is fast, but due to Jest's test isolation, slow user code often exacerbates performance issues and leads to slow test runs. When tests leave behind open handles like unclosed timers or connections to other services, it can cause Jest to hang or slow down. Jest 30 has gotten better at detecting and reporting these issues, which helps you identify and fix slow or problematic tests more easily. For example, tests at [Happo](https://happo.io/) were sped up by 50% from 14 minutes down to 9 minutes by cleaning up open handles and upgrading to Jest 30. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lencioni is this correct and are you ok with this mention?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The mention is good, thank you!
It might be clearer to rephrase the speed up bit like this:
Jest is fast, but due to Jest's test isolation, slow user code often exacerbates performance issues and leads to slow test runs. When tests leave behind open handles like unclosed timers or connections to other services, it can cause Jest to hang or slow down. Jest 30 has gotten better at detecting and reporting these issues, which helps you identify and fix slow or problematic tests more easily. For example, tests at [Happo](https://happo.io/) were sped up by 50% from 14 minutes down to 9 minutes by cleaning up open handles and upgrading to Jest 30. | |
Jest is fast, but due to Jest's test isolation, slow user code often exacerbates performance issues and leads to slow test runs. When tests leave behind open handles like unclosed timers or connections to other services, it can cause Jest to hang or slow down. Jest 30 has gotten better at detecting and reporting these issues, which helps you identify and fix slow or problematic tests more easily. For example, test times at [Happo](https://happo.io/) improved from 14 minutes down to 9 minutes—a 36% reduction—by cleaning up open handles and upgrading to Jest 30. |
This 36% number also matches the math done in the previous paragraph (from 1350s to 850s being a 37% reduction).
website/blog/2025-06-04-jest-30.md
Outdated
Jest 30 delivers real-world performance gains thanks to many optimizations, especially related to module resolution, memory usage, and test isolation. By relying on the new [unrs-resolver](https://github.com/unrs/unrs-resolver), module resolution in Jest became more feature rich, standards compliant, and faster. Thanks to [@JounQin](https://github.com/JounQin) for the migration. Depending on your project, you may see significantly faster test runs and reduced memory consumption. For example, one large TypeScript app with a client and server observed 37% faster test runs and 77% lower memory usage in one part of their codebase: | ||
|
||
| | Jest 29 | Jest 30 | | ||
| ---------------- | ------------------- | ---------------------- | | ||
| **Server tests** | ~1350s / 7.8 GB max | **~850s / 1.8 GB max** | | ||
| **Client tests** | ~49s / 1.0 GB max | **~44s / 0.8 GB max** | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MillerSvt can we mention the source/company here? Who is this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great!
e25edb6
to
4f5465e
Compare
Did another iteration + added a "What's Next" section. |
be955b5
to
0df129f
Compare
0df129f
to
083bb8c
Compare
Jest 30 has shipped. Thanks everyone. |
ToDo