Skip to content

fix(vscode): lower engines.vscode floor for fork compatibility; dual-publish script; release 3.0.4#740

Merged
waleedkadous merged 3 commits into
mainfrom
fix/vscode-engines-fork-compat
May 13, 2026
Merged

fix(vscode): lower engines.vscode floor for fork compatibility; dual-publish script; release 3.0.4#740
waleedkadous merged 3 commits into
mainfrom
fix/vscode-engines-fork-compat

Conversation

@amrmelsayed
Copy link
Copy Markdown
Collaborator

@amrmelsayed amrmelsayed commented May 13, 2026

Summary

Three commits on this branch, in causal order:

  1. fix(vscode): lower engines.vscode floor to 1.105 for fork compatibility — the actual fix
  2. feat(release): scripts/publish-vscode.sh for dual-publish to Marketplace + Open VSX — release tooling (independent of the fix)
  3. chore(vscode): release 3.0.4 — the release event

Why

The cluesmith.codev-vscode@3.0.3 already on both registries declares engines.vscode: ^1.110.0, which blocks installation on VSCode-based forks running older bases:

Host VSCode base 3.0.3 (^1.110.0) 3.0.4 (^1.105.0)
Cursor 3.3.30 1.105.1 ❌ blocked
Antigravity 1.107.0 1.107.0 ❌ blocked
AWS Kiro 0.12.184 1.107.1 ❌ blocked
Windsurf (latest) ≥1.110
Standard VSCode ≥1.110

Cursor was the tightest constraint at 1.105.1. ^1.105.0 is the tightest floor that satisfies all four forks — no speculation about untested host versions.

Hidden bug we also closed

@types/vscode was declared ^1.110.0 but resolved to 1.115.0 via the caret. That meant tsc was happily validating the codebase against 5 minor versions of newer API surface than the engine constraint actually promised — a silent staleness window where we could use a 1.115-only API and ship a runtime-broken build to a 1.110 host.

Pinned to ~1.105.0 now: tsc validates against exactly what we promise to support. check-types passed cleanly at 1.105, so no APIs from 1.106-1.115 were in use anyway.

Dual-publish script (commit 2)

scripts/publish-vscode.sh packages once with vsce package --no-dependencies then uploads the same .vsix to both the VS Code Marketplace and Open VSX. Single-source-of-bytes — avoids the small risk of two consecutive publishes each re-triggering vscode:prepublish and producing functionally-equivalent but byte-different bundles.

scripts/publish-vscode.sh                # stable, both registries
scripts/publish-vscode.sh --pre-release  # pre-release channel, both registries

Auth: VSCE_PAT (or vsce login cluesmith in the OS keychain) and OVSX_PAT (ovsx has no keychain, so export from shell rc / 1Password / macOS Keychain). Script fails fast if OVSX_PAT is missing — no half-publishes.

Extension Links

VS Marketplace: https://marketplace.visualstudio.com/items?itemName=cluesmith.codev-vscode
VSX Open Registry: https://open-vsx.org/extension/cluesmith/codev-vscode

VS Fork Smoke Testing

Cursor

cursor

Kiro

aws-kiro

Antigravity

antigravity

Windsurf

windsurf

Test plan

  • tsc check-types green at ~1.105.0 — no 1.106-1.115 APIs in use
  • pnpm bump-vscode-version correctly promoted ## [Unreleased]## [3.0.4] - 2026-05-13
  • vscode/package.json byte-preserving rewrite preserved (no JSON reformatting)
  • After merge: scripts/publish-vscode.sh succeeds on both registries
  • After publish: install cluesmith.codev-vscode@3.0.4 in Cursor 3.3.30 / Antigravity 1.107.0 / Kiro 0.12.184 — all three should accept

The previous floor of ^1.110.0 blocked installation on VSCode-based forks
running older bases:

  - Cursor 3.3.30       → VSCode 1.105.1
  - Antigravity 1.107.0 → VSCode 1.107.0
  - AWS Kiro 0.12.184   → VSCode 1.107.1
  - Windsurf (latest)   → VSCode 1.110+ (unaffected)

Cursor was the tightest constraint at 1.105.1. Setting engines.vscode to
^1.105.0 satisfies all four hosts plus standard VSCode 1.110+.

Also pin @types/vscode to ~1.105.0 (was ^1.110.0, resolving to 1.115.0).
The caret was letting tsc validate against a much newer API surface than
the engine constraint declared — meaning we could silently start using an
API from 1.106-1.115 with no compile-time guard against an older host
hitting a runtime "is not a function". The tilde now anchors tsc to the
actual supported surface; any drift will fail check-types instead of
shipping latent.

tsc check-types passes at 1.105 — no APIs in 1.106-1.115 are in use.
…ace + Open VSX

Single-script publish flow that packages the extension once with
`vsce package --no-dependencies` then uploads the identical .vsix to
both the VS Code Marketplace (vsce publish --packagePath) and Open VSX
(ovsx publish). Both registries receive byte-identical artifacts —
avoids the small risk of two consecutive `vsce publish` + `ovsx publish`
runs each re-triggering the prepublish hook and producing functionally
equivalent but byte-different bundles.

Usage:
    scripts/publish-vscode.sh                # stable channel, both registries
    scripts/publish-vscode.sh --pre-release  # pre-release channel, both registries

Requires VSCE_PAT (or `vsce login cluesmith` in the OS keychain) and
OVSX_PAT (ovsx has no keychain support — export from shell rc / secrets
manager / macOS Keychain).

Fails fast if OVSX_PAT is missing so we don't half-publish (Marketplace
done, Open VSX skipped). Failure recovery is documented inline: both
registries reject duplicate-version re-uploads, so retry the failed
registry with the existing .vsix on disk.
@amrmelsayed amrmelsayed requested a review from waleedkadous May 13, 2026 10:16
@waleedkadous waleedkadous merged commit c988b84 into main May 13, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants