Restructure VSCode extension publishing for failure isolation#4255
Merged
Conversation
🦋 Changeset detectedLatest commit: 56f96ca The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
trevor-scheer
force-pushed
the
trevor/fix-ovsx-publish
branch
from
0ada5da to
2ee7249
Compare
Contributor
|
The latest changes of this PR are not available as canary, since there are no linked |
trevor-scheer
force-pushed
the
trevor/fix-ovsx-publish
branch
2 times, most recently
from
124ed19 to
d7ee33d
Compare
Set `privatePackages.tag` to `true` so `changeset publish` emits "New tag" lines for private packages (the three VSCode extension packages). `changesets/action` will then create GitHub Releases for them, matching the behavior for public npm packages. Also set `privatePackages.version: true` explicitly — it already matches the default, but documents intent and is defensive against future default changes. Bump the `$schema` URL to `@changesets/config@3.0.2` to match the installed version (was stale at `2.0.1`).
Adds a typed release-orchestration script with four commands: - `build` — runs `vsce:package` for each just-released VSCode workspace. - `attach` — uploads each built `.vsix` to its GitHub Release tag via `gh release upload --clobber`. - `publish-vsce` — publishes each `.vsix` to the VSCode Marketplace via `@vscode/vsce`'s `publishVSIX` (with `skipDuplicate`). - `publish-ovsx` — publishes each `.vsix` to Open VSX via `ovsx`'s `publish` (with `skipDuplicate`). Inspects the returned `PromiseSettledResult[]` and throws if any target was rejected. Each command operates only on the extensions actually released in this run (filtered from the Changesets `publishedPackages` env var) and aggregates failures across packages rather than short-circuiting on the first error. Also pulls `@vscode/vsce` and `ovsx` up to root devDependencies (at the same versions the workspaces already use) so the script can import their JS APIs directly with proper TypeScript types. They go in `devDependencies` rather than `dependencies` because the root monorepo isn't published and they're dev tooling — `js-green-licenses` skips devDeps via `dev: false`.
Replaces the old per-workspace `vsce:publish && open-vsx:publish` chain (which short-circuited on the first failure and was swallowed by the top-level `release` script's `wsrun ... || true`) with a flow built around the new orchestration script: - The `release` job runs Changesets, then for any newly-released VSCode extension: builds the `.vsix` (`release-vscode.mts build`), attaches it to its GitHub Release tag (`release-vscode.mts attach`), and uploads the `.vsix` files as a `vscode-extensions` workflow artifact. - A separate `publish-vscode-extensions` matrix job (per registry) downloads the artifact and runs `release-vscode.mts publish-vsce` or `publish-ovsx`. The two registry shards run independently — a `vsce` failure no longer blocks `ovsx`, and the GHA UI shows them as distinct statuses. Also simplifies the top-level `release` script to drop `wsrun`; the workspace-level scripts it used to invoke are removed in the next commit. `--skipDuplicate` on both publishers makes reruns idempotent. When automated publishing is unavailable (expired PAT, registry down), the `.vsix` is still available on the GitHub Release for manual upload.
The old release flow ran per-workspace `release`, `vsce:publish`, and `open-vsx:publish` scripts (plus a `vsce:prepublish` hook in two of the workspaces). All of those are now dead callers — publishing goes through `scripts/release-vscode.mts`'s programmatic `publishVSIX` / `ovsx.publish` APIs. `vsce:package` is kept; it's still used by the script's `build` command and by the manual local-test flow documented in `vscode-graphql-syntax/README.md`. Also adds a `VSCode extension releases` section to `RELEASING.md` covering what the script does, why we attach `.vsix` files to GitHub Releases (registry redundancy / manual re-uploads / users who want the exact bits), and why the logic lives in a type-checked TS file rather than `run:` bash blocks in `release.yml`.
The previous release attempted to publish these extensions but failed (`vsce:publish` errored, which short-circuited `open-vsx:publish` too). Bump patch versions to deliver the marketplace updates that were skipped.
trevor-scheer
force-pushed
the
trevor/fix-ovsx-publish
branch
from
d7ee33d to
56f96ca
Compare
Merged
trevor-scheer
pushed a commit
that referenced
this pull request
May 14, 2026
This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated. # Releases ## vscode-graphql@0.13.4 ### Patch Changes - [#4255](#4255) [`42d6049`](42d6049) Thanks [@trevor-scheer](https://github.com/trevor-scheer)! - Burning patch version due to previous release failure. ## vscode-graphql-execution@0.3.4 ### Patch Changes - [#4255](#4255) [`42d6049`](42d6049) Thanks [@trevor-scheer](https://github.com/trevor-scheer)! - Burning patch version due to previous release failure. ## vscode-graphql-syntax@1.3.10 ### Patch Changes - [#4255](#4255) [`42d6049`](42d6049) Thanks [@trevor-scheer](https://github.com/trevor-scheer)! - Burning patch version due to previous release failure. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
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.
Summary
The last release silently failed to publish the vscode extensions.
vsce:publishfailed because of an expired PAT, and since each VSCode workspace'sreleasescript chained it with&&,open-vsx:publishnever ran. The top-levelreleasescript then masked the whole thing behindwsrun ... || true, so CI passed and I only happened to notice when I was skimming the logs. There is also no good way to grab the built.vsixfor a manual marketplace upload.Changes
privatePackages.tagin the changesets config sochangesets/actioncreates a GitHub Release for each of the three VSCode extension packages.scripts/release-vscode.mtsto own the VSCode.vsixlifecycle. It exposes four commands that the workflow calls:build,attach,publish-vsce, andpublish-ovsx. Publishing now goes through@vscode/vsce'spublishVSIXandovsx'spublishdirectly (withskipDuplicate), iterating over just the extensions that were actually released in the run. If one package fails, the others still get attempted and the script throws at the end, so failures don't silently short-circuit. It type-checks underscripts/tsconfig.jsonlike the other scripts in there.release.yml. Thereleasejob builds the.vsixfiles, attaches them to the matching GitHub Releases, and uploads them as a workflow artifact. A secondpublish-vscode-extensionsjob runs as a matrix with one shard per registry, downloads the artifact, and runs the right publish command. The shards run independently, so avscefailure doesn't blockovsx, and each shows up as its own status in the GHA UI.release,vsce:publish,open-vsx:publish, andvsce:prepublishscripts. Publishing lives in the script now and nothing else calls them.vsce:packagestays put because the script'sbuildcommand and the manual local-testing flow both still use it.RELEASING.md, including why we attach.vsixfiles to GitHub Releases and why the logic is a TypeScript file instead ofrun:bash blocks.If automated publishing is ever unavailable (expired PAT, registry down), the
.vsixfiles are on the GitHub Release for manual upload.Test plan
The workflows get exercised on the follow-up release this PR triggers.