fix(vscode): lower engines.vscode floor for fork compatibility; dual-publish script; release 3.0.4#740
Merged
Merged
Conversation
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.
waleedkadous
approved these changes
May 13, 2026
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
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.
Summary
Three commits on this branch, in causal order:
fix(vscode): lower engines.vscode floor to 1.105 for fork compatibility— the actual fixfeat(release): scripts/publish-vscode.sh for dual-publish to Marketplace + Open VSX— release tooling (independent of the fix)chore(vscode): release 3.0.4— the release eventWhy
The
cluesmith.codev-vscode@3.0.3already on both registries declaresengines.vscode: ^1.110.0, which blocks installation on VSCode-based forks running older bases:^1.110.0)^1.105.0)Cursor was the tightest constraint at 1.105.1.
^1.105.0is the tightest floor that satisfies all four forks — no speculation about untested host versions.Hidden bug we also closed
@types/vscodewas declared^1.110.0but resolved to1.115.0via 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.0now: tsc validates against exactly what we promise to support.check-typespassed cleanly at 1.105, so no APIs from 1.106-1.115 were in use anyway.Dual-publish script (commit 2)
scripts/publish-vscode.shpackages once withvsce package --no-dependenciesthen uploads the same.vsixto both the VS Code Marketplace and Open VSX. Single-source-of-bytes — avoids the small risk of two consecutive publishes each re-triggeringvscode:prepublishand producing functionally-equivalent but byte-different bundles.Auth:
VSCE_PAT(orvsce login cluesmithin the OS keychain) andOVSX_PAT(ovsx has no keychain, so export from shell rc / 1Password / macOS Keychain). Script fails fast ifOVSX_PATis 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
Kiro
Antigravity
Windsurf
Test plan
~1.105.0— no 1.106-1.115 APIs in usepnpm bump-vscode-versioncorrectly promoted## [Unreleased]→## [3.0.4] - 2026-05-13scripts/publish-vscode.shsucceeds on both registriescluesmith.codev-vscode@3.0.4in Cursor 3.3.30 / Antigravity 1.107.0 / Kiro 0.12.184 — all three should accept