chore(deps-dev): bump vitest from 2.1.9 to 4.0.6 - #1207
Closed
dependabot[bot] wants to merge 1 commit into
Closed
Conversation
Bumps [vitest](https://github.com/vitest-dev/vitest/tree/HEAD/packages/vitest) from 2.1.9 to 4.0.6. - [Release notes](https://github.com/vitest-dev/vitest/releases) - [Commits](https://github.com/vitest-dev/vitest/commits/v4.0.6/packages/vitest) --- updated-dependencies: - dependency-name: vitest dependency-version: 4.0.6 dependency-type: direct:development update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
Comment on lines
20934
to
20939
| "nodemon": "^3.1.10", | ||
| "prettier": "^3.5.3", | ||
| "tsup": "^8.5.0", | ||
| "vitest": "^2.0.5" | ||
| "vitest": "^4.0.6" | ||
| } | ||
| }, |
There was a problem hiding this comment.
The dev dependency for packages/collaboration-yjs has been updated to vitest ^4.0.6, but the lockfile still resolves that workspace’s node_modules/vitest to 2.1.9. Because npm ci requires the lockfile to satisfy the declared ranges, installs will now fail with an invalid: vitest@2.1.9 error for this package. Regenerate package-lock.json so the resolved version under packages/collaboration-yjs also points to 4.0.6.
Useful? React with 👍 / 👎.
Contributor
Author
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
superdoc-bot Bot
pushed a commit
that referenced
this pull request
Aug 2, 2026
![superdoc-oss-port[bot]](https://github.githubassets.com/images/gravatars/gravatar-user-420.png){kind=avatar}
* fix(release): stop V1 claiming the npm dist-tags owned by V2
`superdoc` is published to one npm package name by two release lines that
do not coordinate. Both claimed `latest` and `next`, and npm dist-tags are
last-write-wins, so whichever line published most recently owned them. V1
publishes more often, so V1 won: it took `latest` back on 30 Jul via a
stable release, and `next` on 31 Jul via a push to main, 24 minutes after
V2 had published there.
Tag ownership is now explicit. V2 keeps `latest` and `next`; V1 becomes a
maintenance line under `legacy`. The V1 stable lane stays automatic, so
maintenance releases still ship without manual work — only the tag they
land on changes.
Three separate paths could reach npm, and all three had to agree. The
release config sets the channel, the stable orchestrator's recovery derives
a tag from the version string alone, and the release workflow ran
semantic-release on every push to main. Removing the push trigger alone
would have left a manual dispatch able to cut a real release, so that
workflow now publishes `pr-<number>` previews and nothing else.
The guard encodes all five invariants and fails closed in the mirror-check
lane that already runs on every PR. It rejects the pre-fix state on all six
counts, so it would have caught this before it reached the registry.
* fix(release): close three false-pass gaps in the tag-ownership guard
Each invariant checked that some text existed rather than that the
behaviour was right, so three configurations passed the guard while still
publishing V1 to a tag V2 owns.
The stable channel check looked for `legacy` anywhere in the config, so a
config mapping stable to `canary` while some maintenance branch carried
`legacy` passed. It now parses branch objects and asserts the mapping.
The preview workflow check rejected push triggers and semantic-release but
never required a dist-tag. `publish-superdoc.cjs` defaults to `latest`, so
a dispatch-only workflow running it bare would have taken `latest` on the
next preview. Every invocation must now carry an explicit
`pr-${{ inputs.pr_number }}`, and pr_number must be required and numeric.
The recovery check only looked for `stableDistTag: 'legacy'` in the
descriptor, which proves nothing on its own: dropping the `pkg` argument at
a call site restores the `latest` fallback and leaves the descriptor
untouched. The resolver moves to its own module so it can be imported and
tested directly — release-local-stable.mjs runs the release loop at import
time and cannot be — and the guard now asserts both call sites forward the
package and that the shared module is used rather than a local copy.
All three are covered by regression tests built from the configurations
that reproduced them. The guard now reports nine violations against pre-fix
main, up from six.
Both new test files run in the mirror-check lane. release-local.test.mjs is
not wired into CI, which is how its five pre-existing failures went unseen;
that is left alone here rather than widened into this change.
* fix(release): keep the scoped mirror on latest and close four guard bypasses
The scoped mirror was collateral damage from the tag split. Codex caught it:
`publish-superdoc.cjs` passed one dist-tag to both `superdoc` and
`@harbour-enterprises/superdoc`, so routing V1 stable to `legacy` would have
taken the scoped package's `latest` with it. That package is V1-only —
nothing else advances it — so its `latest` would have frozen at 1.45.1 and
default installs would have silently stopped updating. The two names now
resolve their stable tag independently; previews and prereleases still match
under both.
Writing that test surfaced a temporal dead zone: `scopedTagFor` sat below the
`require.main` block that `parseArgs` runs from, so every direct invocation
threw "Cannot access before initialization" — the path release recovery uses.
Moved above its first reference and covered by a test.
Four guard bypasses, each reproduced before fixing. `pr_number` validation
matched `required:`/`type:` anywhere in the trigger block, so a required
numeric sibling input satisfied an optional string `pr_number`; it now parses
that input's own block. The recovery audit accepted any number of safe calls,
so one site could hardcode `latest` while the other vouched for it; it now
asserts both named assignments resolve through the shared helper. The branch
parser scanned to the next `name:` token rather than the object boundary, so
a later object's channel was read as stable's; it now matches braces. And the
workflow audit inventoried only `publish-superdoc.cjs`, so a direct
`dist-tag add` could reclaim a tag beside a correctly tagged preview.
Guard now reports ten violations against pre-fix main, up from nine.
Qodo also flagged `superdoc` in the workflow title as a naming violation.
Not taken: the sibling release workflows use the lowercase package name the
same way, and it refers to the npm package rather than the product.
Note: this ports only the public subtree changes from a mixed source commit (8 public paths, 5 non-public paths ignored).
Ported-From-Source-Repo: superdoc/orbit
Ported-From-Source-Commit: c4447f0b00bc324edb5e39cfe0cb557bd6796e8c
Ported-Public-Prefix: superdoc/public
superdoc-orbit Bot
pushed a commit
that referenced
this pull request
Aug 2, 2026
### Chores - 1.21.3 [skip ci] - 0.22.2 [skip ci] - 1.45.1 [skip ci] ### Changes - Merge remote-tracking branch 'origin/main' into merge/main-into-stable-2026-08-02 ### Bug Fixes - stop V1 claiming the npm dist-tags owned by V2 (#1207) - v1 w:ins/w:del lose tracking when a run begins with w:noBreakHyphen (#1139)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps vitest from 2.1.9 to 4.0.6.
Release notes
Sourced from vitest's releases.
... (truncated)
Commits
2e7b2b8chore: release v4.0.631706dffix: reuse the same environment whenisolateandfileParallelismare fals...10a06d8fix(happy-dom): properly teardown additional keys (#8888)197caf2fix(jsdom): pass down Node.jsFormDatatoRequest(#8880)ca041f5fix: improve spying types (#8878)e3b7775fix(coverage): prevent filtering out virtual files before remapping to source...7e6c37afix: do not throw when importing a type from an external package (#8875)3e19f27fix: don't merge errors with different diffs for reporting (#8871)ed9fc71chore: release v4.0.5b9521e0fix: allow module in --config (#8864)Maintainer changes
This version was pushed to npm by [GitHub Actions](https://www.npmjs.com/~GitHub Actions), a new releaser for vitest since your current version.
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)