vscode-jest's newest release is from June 2025, its last push was in March, and the README points at the wrong previous version

The release line stopped in June 2025 and the last push was in March

The dates in this repository describe two different clocks, and they have both stopped.

Three tags are visible. The newest is v6.4.4, whose release name carries its own date, June 29, 2025. Before it, v6.4.3 on May 5, 2025, and a prerelease tag written as v6.4.2-next on April 19, 2025. The manifest carries the same number as the newest release, 6.4.4.

So the release line stopped about fifteen months ago. One of the three tags is a prerelease on the 2 line, which means the project shipped a next build of a patch that was then superseded twice.

The push clock is separate and ran longer. The last recorded push is 2026-03-20, roughly nine months after the newest tag, which means development continued for a while after the last release and then also went quiet, about six and a half months ago. The repository is not archived.

That shape is worth stating plainly rather than paraphrasing as a maintenance judgement: there is a published extension on the marketplace, its version is fixed, and there is no cadence to it. If you install it today you get 6.4.4 and you will keep getting 6.4.4 until a new tag appears.

The features list ends with a claim about community support rather than about releases, which is the only forward-looking sentence in the document.

The README names v6.4.0 as the previous release and v6.4.3 exists

The Releases section of the README is two lines long and one of them points at a version that is not the previous one.

The current release is named as v6.4.4, linking to an anchor inside a file called `release-note-v6.md`. The previous release is named as v6.4.0, linking to the anchor for v6.4.0 in the same file. A third link points at an index of all release notes.

The tag list includes v6.4.3 and v6.4.2-next. So the version called previous is two patch releases behind the newest one, and the patch releases in between are reachable only through the index.

The release notes themselves are part of the repository rather than attached to the tags. There is a directory holding them, one file per major line with an anchor per patch release, and an index file that links to all of them. That is a deliberate choice: the notes are versioned alongside the code, so a checkout of a given tag has the notes for that version.

It also means the two headline links in the document are the first thing a reader clicks and the one that is out of date is the second. If you arrive looking for what changed in 6.4.3 or 6.4.2, the document will not point you there.

Six activation patterns, and the extension runs in the workspace host

How the extension decides to wake up is written out as six patterns, four of which look for a file and two of which look for a binary.

"activationEvents": [
  "workspaceContains:**/jest.config.{js,ts,mjs,cjs,json}",
  "workspaceContains:**/jest.json",
  "workspaceContains:node_modules/.bin/jest",
  "workspaceContains:node_modules/react-scripts/node_modules/.bin/jest",
  "workspaceContains:node_modules/react-native-scripts",
  "workspaceContains:**/.vscode-jest"
],

The first pattern covers five config file extensions in one brace group, which is why a TypeScript or ESM config is found without a separate entry. The fourth pattern is the interesting one: it looks for a Jest binary nested inside a react-scripts install, which is where a create-react-app project keeps it rather than at the top of `node_modules`. The last pattern is a marker directory named for the extension, which is how a project with a non standard layout opts in explicitly.

Two other manifest fields explain the architecture. The extension declares its kind as workspace, so it runs in the workspace extension host rather than the user interface host, which is what lets it start child processes and watch for file changes. And its entry point is a compiled file under an `out` directory, which the tree explains with a production TypeScript configuration and a bundler configuration sitting next to it.

The compiled entry point also means the extension ships built output rather than sources, and the packaging ignore file is what keeps the test and configuration directories out of it.

The marketplace publisher is still Orta and the repository is under jest-community

The extension moved organisation and kept its marketplace identity, which is visible in the fields that have to agree.

The manifest names the package `vscode-jest`, gives it a display name of simply `Jest`, and its marketplace description is a sentence about using Jest with pleasure rather than a description of what it does. The publisher is `Orta`, and the marketplace item identifier in the install link is `Orta.vscode-jest`. The repository field points at `jest-community/vscode-jest`.

The author field lists three people, and the repository is a community one, so the split is between the marketplace listing, which keeps the original publisher, and the source, which moved.

That matters for anyone installing by identifier or writing documentation that links to the extension: the search and install paths are the publisher-prefixed one, and the source is not.

The rest of the metadata is small and conventional. Two categories, `Other` and `Testing`. Five keywords, including `multi-root ready`, which is the only functional claim in that list and matches a feature further down about running several Jest processes in one workspace folder. A gallery banner with a single colour and a dark theme, and an icon file.

The description being a joke rather than a summary is worth noting only because it is what appears in the marketplace listing, which is the first thing a new user reads.

It registers a language mode so snapshot files get their own highlighting

Among the things the extension contributes to the editor is an entire language definition, and it is the one most extensions do not do.

The contribution names a language with the identifier `jest-snapshot` and registers four file extensions for it: `.js.snap`, `.jsx.snap`, `.ts.snap` and `.tsx.snap`. It points that language at a configuration file in the repository root, and then contributes a grammar for the same language with the scope name `source.jest.snap` and a TextMate grammar file under a `syntaxes/` directory.

So snapshot files are not treated as text or as some existing language. They get their own scope, their own grammar and their own editor configuration, and the tree carries the two files that back it plus a `language-configuration.json`. That is what allows the extension to show and update snapshots interactively rather than opening them as a wall of quoted strings, which is one of the features it advertises.

The feature list also claims coverage information shown inside the files being tested, inline reporting of failures from the assertion function in both the editor and the problem inspector, and extra completion for the test framework's own methods.

Two of those are cheap to add once the test run is parsed, and the snapshot language mode is the one that required writing a grammar, which is consistent with it appearing in the manifest rather than only in the prose.

runMode is a session choice because the right answer changes within a project

One of the documented settings gets a paragraph of justification, and the paragraph explains why a settings file is the wrong place for it.

Run mode decides the overall shape of the experience: when tests run, whether coverage is collected while they run, and how errors are displayed. Different modes carry different performance implications, particularly on larger projects. And the stated reason for not leaving it in configuration is that the preference changes inside a single project: a developer making light edits wants a watching mode so nothing breaks silently, and the same developer doing heavy test work wants an on demand mode for more control over execution. The document's conclusion is that a static configuration in the settings file is simply not sufficient.

So the extension ships a switcher for it, letting the mode change without permanently editing the settings file. That is a small interface decision with a real justification, and it is the kind of thing that only gets written down after people kept reopening the settings file.

Thirteen settings are documented in total, including the command line override for using a different test command, the project root, the coverage formatter and its colours, the output configuration, automatic running, the test explorer panel, the shell, a long run monitor, an output reveal toggle, parser plugin options and virtual folders. The first one in the manifest is a boolean that enables or disables the extension for a workspace folder and defaults to true.

Debug configuration is documented twice, once for the original shape and once labelled as a second version, which tells you both generations of it are still described in the same document.

Six troubleshooting entries, two of them about the extension being invisible

The troubleshooting section is six headings, and reading them as a list tells you what actually goes wrong.

The first is Jest failing to run at all. The second is a performance question, which the features and interface sections both promise to answer by pointing here. The third is intermittent errors for the package manager or node command not being found during a test run or while debugging, which is a process resolution problem rather than a Jest problem. The fourth is not seeing Jest in the bottom status bar. The fifth is what to do about a long running tests warning. And the sixth is tests and status not matching, or some tests showing question marks unexpectedly.

So two of the six are about the extension failing to announce itself rather than about tests failing, and two more are about performance and process resolution. Only one is a straightforward Jest execution failure.

The tree supports that reading. There is a setup wizard document at the top level, and two editor configuration directories are committed, one for the stable build and one for the insiders build, which is how a project that ships to both channels keeps their launch configurations side by side.

Also worth noting is what the repository uses for its own tooling. It has a lockfile for one package manager, an ESLint configuration in the older single file JavaScript form, a Jest configuration for testing itself, and a separate TypeScript configuration for the production build.

Editorial conclusion

Fit this if you already have Jest working and want the editor to drive it rather than watching a terminal, and if the defaults suit a project that runs on a single Jest process. The two features that distinguish it are the run mode quick switch and the snapshot handling, both of which address a problem other runners leave you to solve by editing a settings file mid task. Four things to know before you rely on it. Which release you are on, since the newest tag is from June 2025 and the last recorded push is 2026-03-20, so your editor will not receive updates on a schedule. Which previous release the documentation points you at, because the README names a version two patches behind the newest one as previous. How many Jest processes your workspace starts, since several at once is supported and is a different performance story from one. And whether you need the extra settings at all, since there are thirteen documented ones and the first of them can switch the whole extension off for a folder.

Frequently asked questions

Official sources

1. Issues
2. jest-community/vscode-jest on GitHub
3. License: MIT
4. README
5. Releases