devops: publish from the Highflame org as @highflame/codeoid, 0.4.0 - #269
Merged
Conversation
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
saucam
force-pushed
the
devops/release-0.4.0-highflame-scope
branch
from
August 5, 2026 03:31
71b318e to
3df0d2b
Compare
akashjavelin
approved these changes
Aug 5, 2026
Packages the release-prep change that was sitting uncommitted in the working tree. The rename itself is not my work — I committed it as-is and verified it, rather than authoring it. What it does: - the npm package becomes `@highflame/codeoid`, with the workspaces renamed to match (`@highflame/codeoid-protocol`, `@highflame/codeoid-core`) and every import updated - `publishConfig.access: public`, since a scoped package defaults to restricted and would otherwise fail to publish - version 0.4.0 - README / CHANGELOG / RELEASING / workflow updates, including the note that the unscoped `codeoid` package is deprecated and stops at 0.3.4 The command stays `codeoid`. Verified before committing, because a rename is exactly the change that looks fine and breaks resolution: - zero remaining `@codeoid/` references anywhere under `src/`, `packages/`, or `web/src/` — the rename is total, not partial - biome clean over 346 files; `tsc --noEmit` clean across the root and both workspaces - `bun run build` succeeds, so workspace resolution actually works under the new names rather than only type-checking - full suite: 2172 pass, 12 skip, 0 fail Kept as its own commit and PR deliberately. It touches package identity and version — a publishing decision with consequences for anyone installing the old name — and folding it into a feature branch would have buried that under unrelated review. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The three publish steps ran a bare `npm publish`, which fails if that exact version is already on the registry. Two consequences worth removing before this pipeline carries a real release: - the bootstrap release of a NEW package name is published by hand (npm will not attach a Trusted Publisher to a package that does not exist yet), so the tag that follows it always left a red release run behind; - a job that died after a partial publish could not be re-run — the retry tripped over whichever packages had already landed. Route each publish through scripts/publish-if-new.sh, which skips a name@version that is already published. This is not a concession to version drift; `check:versions` still makes drift impossible and this script says nothing about which version is correct. A registry error that is not a 404 fails the step rather than being silently read as "not published yet", so an outage cannot masquerade as a publishable state. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
saucam
force-pushed
the
devops/release-0.4.0-highflame-scope
branch
from
August 6, 2026 08:26
3df0d2b to
9b2583d
Compare
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
2 participants
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.
Release prep: codeoid publishes from the Highflame org as
@highflame/codeoid, at 0.4.0.Attribution: the rename itself is not my work — it was sitting uncommitted in the working tree. I packaged it, verified it, and kept it in its own PR rather than authoring it.
What changes
@highflame/codeoid, with workspaces renamed to match (@highflame/codeoid-protocol,@highflame/codeoid-core) and every import updatedpublishConfig.access: public— a scoped package defaults torestrictedand would otherwise fail to publishcodeoidpackage is deprecated and stops at0.3.4The command is still
codeoid.Verification
A rename is exactly the change that type-checks while breaking resolution, so this was checked at the level that matters:
@codeoid/refs undersrc/,packages/,web/src/tsc --noEmit(root + both workspaces)bun run buildtsc -b, eslint, vitestRe-verified after rebasing onto merged
main(9c677d1), not only on the branch it was authored against.Why it's separate
It touches package identity and version — a publishing decision with consequences for anyone installing the old name. Folding it into a feature branch would have buried that under unrelated review.
Note for the reviewer
This PR only prepares the rename. Actually publishing deprecates the unscoped
codeoidpackage on npm and redirects users to the scoped one — worth confirming the npm-side steps inRELEASING.mdmatch what you intend before cutting the release.🤖 Generated with Claude Code