fix: npm 0.6.0 version-sync + workflow_dispatch + already-published guard - #33
Merged
Merged
Conversation
…blished guard Opus's decision (no workflow_dispatch on publish-npm.yml today, so the automatic release- triggered publish for extract#31/79acca7's release already fired-and-failed against the stale 0.5.0 npm version -- there is no automatic retry path once npm's version catches up). 1. packages/ts/package.json + package-lock.json: 0.5.0 -> 0.6.0, via `npm version --no-git-tag-version` (keeps both files in sync through npm's own tooling, not hand-edited sed -- avoiding the exact lockfile-drift class Sentinel caught earlier this session). Semantically honest: main already carries the full additive-role ts/py parity slice (schema.ts/builder.ts/validate.ts/finalize.ts/prompt-data.ts all match Python), so the version number now matches what's actually shipped, not a hollow bump. 2. publish-npm.yml: added `workflow_dispatch` trigger alongside the existing `release: published` trigger, so this specific already-fired release can be manually re-triggered once the version genuinely changed. Guarded the release-only step (SBOM upload, which reads github.event.release.tag_name) behind `github.event_name == 'release'` so a manual dispatch doesn't crash on a nonexistent release context. 3. Added an "already published" guard: checks `npm view @synapt-dev/extract@$VERSION version` before publishing: skips publish/SBOM/upload-to-release when that version is already live. Fixes a real noise problem this exact release train just produced: the workflow fires unconditionally on EVERY GitHub release regardless of whether npm's OWN version actually changed, so a future Python-only release (npm version unchanged) will otherwise always fail-red with "cannot publish over previously published version" -- expected, not a bug, but noisy. The guard makes that case a clean skip instead of a red X. CHANGELOG.md: corrected the now-stale "npm keeps 0.5.0 for now" and "+ version-sync" claims from the earlier landed commit -- version-sync is done here; the FULL ts/py parity effort (a TS extract_batch/batch.ts port) remains the separate, still-deferred follow-up. Verified: 265 TS tests green, tsc --noEmit clean, no test hardcodes the package version (checked before assuming safe), publish-npm.yml YAML validated. Premium boundary: OSS -- extract's IL schema/build/CI infrastructure only. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017ZMaT1FQJD6rqfN77piMHm
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.
Resolves the npm 0.6.0 gap (Opus's decision, since
publish-npm.ymlhas noworkflow_dispatchtoday: the automatic release-triggered publish for extract#31's release already fired-and-failed against the stale 0.5.0 npm version — no automatic retry path once npm's version catches up).What's in this PR
packages/ts/package.json+package-lock.json: 0.5.0 → 0.6.0, vianpm version --no-git-tag-version(both files kept in sync through npm's own tooling, not hand-edited — avoiding the exact lockfile-drift class Sentinel caught earlier this session). Semantically honest: main already carries the full additive-role ts/py parity slice, so the version number now matches what's actually shipped.publish-npm.yml: addedworkflow_dispatchalongside the existingrelease: publishedtrigger, so this already-fired release can be manually re-triggered now that the version has genuinely changed. Guarded the release-only SBOM-upload step (readsgithub.event.release.tag_name) behindgithub.event_name == 'release'so a manual dispatch doesn't crash on a nonexistent release context.Added an "already published" guard: checks
npm view @synapt-dev/extract@$VERSION versionbefore publishing, skips publish/SBOM/upload-to-release when that version is already live. Fixes a real noise problem this exact release train just produced — the workflow fires unconditionally on every GitHub release regardless of whether npm's own version changed, so a future Python-only release will otherwise always fail-red ("cannot publish over previously published version") — expected, not a bug, but noisy. The guard turns that into a clean skip.CHANGELOG.md: corrected the now-stale "npm keeps 0.5.0 for now" and "+ version-sync" claims from the earlier landed commit — version-sync is done here; the FULL ts/py parity effort (a TSextract_batch/batch.tsport) remains the separate, still-deferred follow-up.Verification
tsc --noEmitclean.publish-npm.ymlYAML validated.Sequence after merge
Merge → run
gh workflow run publish-npm.yml(using the newworkflow_dispatch) → verifynpm view @synapt-dev/extract version== 0.6.0.Premium boundary
OSS — extract's IL schema/build/CI infrastructure only.
Reviewers: Opus, Sentinel