feat(ogpeek-extension): track in release-please with linked-versions to ogpeek#32
Closed
minjun0219 wants to merge 1 commit into
Closed
feat(ogpeek-extension): track in release-please with linked-versions to ogpeek#32minjun0219 wants to merge 1 commit into
minjun0219 wants to merge 1 commit into
Conversation
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
ogpeek | 3f5f8d1 | Commit Preview URL Branch Preview URL |
May 06 2026, 08:27 AM |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f7f4eb4edd
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "packages/ogpeek": "0.5.0", | ||
| "packages/ogpeek-react": "0.5.0" | ||
| "packages/ogpeek-react": "0.5.0", | ||
| "packages/ogpeek-extension": "0.0.0" |
There was a problem hiding this comment.
When the next push to main runs release-please, this manifest entry makes ogpeek-extension look last released at 0.0.0; I checked the reviewed commit body and it does not contain an actual Release-As: 0.5.0 footer or any config-level release-as. Because the new linked-versions group forces ogpeek and the extension to the highest proposed group version, the first extension release will be computed from 0.0.0 (e.g. 0.1.0) instead of the intended 0.5.0, and can drag the already-released ogpeek package toward that lower version rather than producing only ogpeek-extension-v0.5.0. Seed this package at 0.5.0 or add a real one-time release override before enabling the link.
Useful? React with 👍 / 👎.
Owner
Author
There was a problem hiding this comment.
The reviewed commit f7f4eb4 does carry a Release-As: 0.5.0 footer — git show -s f7f4eb4 confirms it sits at the end of the commit body, just before the session URL. The body of the PR that summarizes the change cites that footer in markdown prose, but the parser-relevant copy lives in the commit itself.
Combined with the path anchor — this commit creates packages/ogpeek-extension/CHANGELOG.md (a file under the extension's tracked path), so Release-As has somewhere to scope to — release-please should pin the first ogpeek-extension cut to 0.5.0, and linked-versions will see 0.5.0 as the highest proposed version in the ogpeek-engine group, leaving ogpeek (already at 0.5.0) untouched.
The earlier sibling fix (#29) failed to apply its Release-As for exactly the path-anchor reason — the commit only modified .release-please-manifest.json, which is not under any tracked package path. That experience is why this PR pre-creates the changelog stub: the diff that ships with this commit must touch a tracked path or the footer goes nowhere.
If the next release-please run still proposes 0.1.0/1.0.0 for the extension despite the footer + anchor, the safety net is the same one used on #31 — manually edit the release PR's manifest / package.json / CHANGELOG to 0.5.0 before merging.
Generated by Claude Code
Owner
Author
There was a problem hiding this comment.
Addressed in 3f5f8d1 — replaced pnpm libs:build with explicit pnpm -F ogpeek build && pnpm -F @ogpeek/react build so the extension publish job is anchored on its own dependency graph (the website filter wasn't load-bearing here, just confusing). Also dropped package:chrome in favor of build:chrome + a direct node ./scripts/zip.mjs chrome step so the libs are built once instead of twice (per Copilot's other comment), and added --clobber to gh release upload for re-run idempotency.
Generated by Claude Code
There was a problem hiding this comment.
Pull request overview
This PR wires the packages/ogpeek-extension workspace into the existing release-please pipeline and links its versioning to ogpeek, then adds a GitHub Actions job to build/package the Chrome extension zip and upload it to the corresponding GitHub Release.
Changes:
- Track
packages/ogpeek-extensioninrelease-please-config.jsonand link versions withogpeekvia thelinked-versionsplugin. - Bootstrap release-please state for the extension in
.release-please-manifest.jsonand add an initialCHANGELOG.mdstub. - Extend the release workflow to conditionally build and upload the extension zip as a GitHub Release asset when an extension release is created.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| release-please-config.json | Adds extension package tracking and links extension+engine versions. |
| .release-please-manifest.json | Bootstraps the extension’s manifest entry for release-please. |
| packages/ogpeek-extension/CHANGELOG.md | Adds a changelog target file for release-please to populate. |
| .github/workflows/release-please.yml | Adds outputs and a publish job to build/package/upload the extension zip to GitHub Releases. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| # ogpeek-extension 는 workspace 의 ogpeek / @ogpeek/react 를 번들하므로 | ||
| # 두 라이브러리를 먼저 빌드해 둔다. | ||
| - name: Build libraries | ||
| run: pnpm libs:build |
Comment on lines
+146
to
+150
| - name: Typecheck | ||
| run: pnpm -F ogpeek-extension typecheck | ||
|
|
||
| - name: Build + package Chrome extension | ||
| run: pnpm -F ogpeek-extension package:chrome |
| - name: Upload zip to GitHub Release | ||
| env: | ||
| GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} | ||
| run: gh release upload "${{ needs.release-please.outputs.extension_tag_name }}" packages/ogpeek-extension/dist/ogpeek-chrome.zip |
…to ogpeek Wire packages/ogpeek-extension (added in #28, dark-theme variants in #30) into the release-please pipeline so the engine and the extension cut releases together at the same version. Distribution stays GitHub-Release-only — no npm — so the publish job builds the Chrome zip and attaches it to the GitHub Release for the cut tag. - release-please-config.json: - Add packages/ogpeek-extension entry. component: "ogpeek-extension" + include-component-in-tag: true so its tags are "ogpeek-extension-vX.Y.Z" and never collide with ogpeek's "vX.Y.Z". - Add a linked-versions plugin (groupName: ogpeek-engine, members: ogpeek + ogpeek-extension) so the two cut releases at the same version. ogpeek-react stays out of the group on its own track. - Set component: "ogpeek" on ogpeek's entry so linked-versions can address it explicitly. include-component-in-tag stays false, so its tag format stays "vX.Y.Z" — npm publish path unchanged. - .release-please-manifest.json: add packages/ogpeek-extension: "0.0.0" — release-please's bootstrap placeholder. Combined with the Release-As footer below this pins the first ogpeek-extension release to 0.5.0, matching the just-cut ogpeek / @ogpeek/react 0.5.0 baseline. - packages/ogpeek-extension/CHANGELOG.md: add as an empty stub so release-please has a file to populate on the first release. Also serves as a path anchor for this commit so the Release-As footer applies to the extension package (not all tracked packages). - .github/workflows/release-please.yml: - Add extension_release_created / extension_tag_name outputs from the release-please job (matching the existing ogpeek_* / react_* shape). - Add publish-ogpeek-extension job: gated on extension_release_created being "true", checks out the extension tag, builds the workspace libs (extension bundles ogpeek + @ogpeek/react), runs the existing package:chrome script to produce dist/ogpeek-chrome.zip, and uploads the zip to the matching GitHub Release via gh release upload. Job uses GITHUB_TOKEN only — no npm credentials, no OIDC dance, since nothing in this path touches npm. The extension's package.json keeps version "0.0.0" + private: true. release-please will write 0.5.0 in the next release PR's commit before merge, and private: true blocks accidental "pnpm publish" from leaking the extension to npm regardless of the version on disk. Release-As: 0.5.0 https://claude.ai/code/session_0162rG86ukDFiBZfqgEADYfp
minjun0219
force-pushed
the
claude/release-please-track-extension
branch
from
f7f4eb4 to
3f5f8d1
Compare
4 tasks
Owner
Author
|
Closing in favor of #33, which restructures release-please to single-package mode (one Generated by Claude Code |
minjun0219
pushed a commit
that referenced
this pull request
May 6, 2026
Restructure the release-please pipeline so the entire monorepo cuts a single coordinated release per cycle — one git tag, one GitHub Release, one CHANGELOG — instead of producing per-package tags and Releases. Why --- The earlier setup tracked each workspace package independently: - packages/ogpeek as bare-tagged "vX.Y.Z" on npm - packages/ogpeek-react as "ogpeek-react-vX.Y.Z" on npm - packages/ogpeek-extension (added in #28/#30) as "ogpeek-extension-vX.Y.Z" on GitHub Releases That's the standard release-please monorepo shape, but it produces asymmetric tag namespaces (one bare, two prefixed) and forces every "do they release together?" question through linked-versions plugin configuration, which we already started running into on #32. In practice all three packages are co-developed and ship together — @ogpeek/react and ogpeek-extension are both wrappers around the engine and aren't useful at versions out of sync with it. Treating them as one product matches reality and removes a class of release-tooling edge cases (phantom bumps, plugin behavior on mismatched starting versions, asymmetric tag formats, missing path anchors for Release-As footers). Changes ------- - release-please-config.json: - Replace the per-package map with a single root entry ("." path). package-name is "ogpeek" (the project name; matches the existing "vX.Y.Z" tag namespace, so v0.5.0 stays a meaningful boundary). - include-component-in-tag stays false → tags are "vX.Y.Z" with no prefix, continuing the existing convention. - extra-files lists every package.json that release-please should bump in lockstep with the root version: ogpeek, @ogpeek/react, ogpeek-extension. release-please's built-in node updater handles each "version" field automatically. - Drop the linked-versions plugin and separate-pull-requests flag — both unnecessary in single-package mode (there's only one component to coordinate). - .release-please-manifest.json: collapse the two per-package entries into a single "." entry at "0.5.0" — matching ogpeek + @ogpeek/react on npm and the existing v0.5.0 tag. - .github/workflows/release-please.yml: - Replace the four per-package outputs with a single release_created + tag_name pair, both keyed against the "." path. - Gate publish-ogpeek and publish-ogpeek-react on the same single output so they always fire together with the new umbrella release. - Add publish-ogpeek-extension that runs alongside the other two: builds the workspace libs explicitly (no reliance on the website-anchored libs:build script), runs build:chrome + the zip script directly to avoid double-building libs through package:chrome, and uploads dist/ogpeek-chrome.zip to the GitHub Release with --clobber for re-run idempotency. This job uses GITHUB_TOKEN only (contents: write) — no npm credentials, no OIDC. Trade-offs ---------- - All three packages always share a version going forward. A fix in one package bumps all three (phantom bump for the others on npm / on a new GitHub Release). Acceptable because the three move together anyway. - Per-package CHANGELOG.md files (packages/ogpeek/CHANGELOG.md, packages/ogpeek-react/CHANGELOG.md) keep their historical entries but won't get new ones — the next release writes only to the root CHANGELOG.md. That's intentional: the umbrella release notes are the new source of truth, scoped per-package via Conventional Commit scopes (feat(ogpeek-extension), fix(ogpeek-react), etc.) inside each entry. - Existing per-component tags (ogpeek-react-v0.5.0) become orphaned but harmless — git keeps them; GitHub keeps the matching Release. Verification after merge ------------------------ This commit is a chore (no Conventional Commit type that triggers a bump), so the release-please run on push will not propose a release. The next feat/fix that lands on main will produce the first single-package-mode release PR — expected: - One "chore: release main" PR with version bumped to 0.5.1 / 0.6.0 / 1.0.0 (per the bump rules) on the root CHANGELOG. - All three package.jsons updated to the new version via extra-files. - Merging cuts a single "vX.Y.Z" tag + a single GitHub Release. - Three publish jobs fire from the one release_created event: publish-ogpeek (npm), publish-ogpeek-react (npm), publish-ogpeek-extension (GitHub Release zip upload). Supersedes #32, which approached the extension-tracking problem within the existing per-package monorepo structure. https://claude.ai/code/session_0162rG86ukDFiBZfqgEADYfp
minjun0219
pushed a commit
that referenced
this pull request
May 6, 2026
Restructure the release-please pipeline so the entire monorepo cuts a single coordinated release per cycle — one git tag, one GitHub Release, one CHANGELOG — instead of producing per-package tags and Releases. Why --- The earlier setup tracked each workspace package independently: - packages/ogpeek as bare-tagged "vX.Y.Z" on npm - packages/ogpeek-react as "ogpeek-react-vX.Y.Z" on npm - packages/ogpeek-extension (added in #28/#30) as "ogpeek-extension-vX.Y.Z" on GitHub Releases That's the standard release-please monorepo shape, but it produces asymmetric tag namespaces (one bare, two prefixed) and forces every "do they release together?" question through linked-versions plugin configuration, which we already started running into on #32. In practice all three packages are co-developed and ship together — @ogpeek/react and ogpeek-extension are both wrappers around the engine and aren't useful at versions out of sync with it. Treating them as one product matches reality and removes a class of release-tooling edge cases (phantom bumps, plugin behavior on mismatched starting versions, asymmetric tag formats, missing path anchors for Release-As footers). Changes ------- - release-please-config.json: - Replace the per-package map with a single root entry ("." path). package-name is "ogpeek" (the project name; matches the existing "vX.Y.Z" tag namespace, so v0.5.0 stays a meaningful boundary). - include-component-in-tag stays false → tags are "vX.Y.Z" with no prefix, continuing the existing convention. - extra-files lists every package.json that release-please should bump in lockstep with the root version: ogpeek, @ogpeek/react, ogpeek-extension. release-please's built-in node updater handles each "version" field automatically. - Drop the linked-versions plugin and separate-pull-requests flag — both unnecessary in single-package mode (there's only one component to coordinate). - .release-please-manifest.json: collapse the two per-package entries into a single "." entry at "0.5.0" — matching ogpeek + @ogpeek/react on npm and the existing v0.5.0 tag. - .github/workflows/release-please.yml: - Replace the four per-package outputs with a single release_created + tag_name pair, both keyed against the "." path. - Gate publish-ogpeek and publish-ogpeek-react on the same single output so they always fire together with the new umbrella release. - Add publish-ogpeek-extension that runs alongside the other two: builds the workspace libs explicitly (no reliance on the website-anchored libs:build script), runs build:chrome + the zip script directly to avoid double-building libs through package:chrome, and uploads dist/ogpeek-chrome.zip to the GitHub Release with --clobber for re-run idempotency. This job uses GITHUB_TOKEN only (contents: write) — no npm credentials, no OIDC. Trade-offs ---------- - All three packages always share a version going forward. A fix in one package bumps all three (phantom bump for the others on npm / on a new GitHub Release). Acceptable because the three move together anyway. - Per-package CHANGELOG.md files (packages/ogpeek/CHANGELOG.md, packages/ogpeek-react/CHANGELOG.md) keep their historical entries but won't get new ones — the next release writes only to the root CHANGELOG.md. That's intentional: the umbrella release notes are the new source of truth, scoped per-package via Conventional Commit scopes (feat(ogpeek-extension), fix(ogpeek-react), etc.) inside each entry. - Existing per-component tags (ogpeek-react-v0.5.0) become orphaned but harmless — git keeps them; GitHub keeps the matching Release. Verification after merge ------------------------ This commit is a chore (no Conventional Commit type that triggers a bump), so the release-please run on push will not propose a release. The next feat/fix that lands on main will produce the first single-package-mode release PR — expected: - One "chore: release main" PR with version bumped to 0.5.1 / 0.6.0 / 1.0.0 (per the bump rules) on the root CHANGELOG. - All three package.jsons updated to the new version via extra-files. - Merging cuts a single "vX.Y.Z" tag + a single GitHub Release. - Three publish jobs fire from the one release_created event: publish-ogpeek (npm), publish-ogpeek-react (npm), publish-ogpeek-extension (GitHub Release zip upload). Supersedes #32, which approached the extension-tracking problem within the existing per-package monorepo structure. https://claude.ai/code/session_0162rG86ukDFiBZfqgEADYfp
minjun0219
pushed a commit
that referenced
this pull request
May 6, 2026
Restructure the release-please pipeline so the entire monorepo cuts a single coordinated release per cycle — one git tag, one GitHub Release, one CHANGELOG — instead of producing per-package tags and Releases. Why --- The earlier setup tracked each workspace package independently: - packages/ogpeek as bare-tagged "vX.Y.Z" on npm - packages/ogpeek-react as "ogpeek-react-vX.Y.Z" on npm - packages/ogpeek-extension (added in #28/#30) as "ogpeek-extension-vX.Y.Z" on GitHub Releases That's the standard release-please monorepo shape, but it produces asymmetric tag namespaces (one bare, two prefixed) and forces every "do they release together?" question through linked-versions plugin configuration, which we already started running into on #32. In practice all three packages are co-developed and ship together — @ogpeek/react and ogpeek-extension are both wrappers around the engine and aren't useful at versions out of sync with it. Treating them as one product matches reality and removes a class of release-tooling edge cases (phantom bumps, plugin behavior on mismatched starting versions, asymmetric tag formats, missing path anchors for Release-As footers). Changes ------- - release-please-config.json: - Replace the per-package map with a single root entry ("." path). package-name is "ogpeek" (the project name; matches the existing "vX.Y.Z" tag namespace, so v0.5.0 stays a meaningful boundary). - include-component-in-tag stays false → tags are "vX.Y.Z" with no prefix, continuing the existing convention. - extra-files lists every package.json that release-please should bump in lockstep with the root version: ogpeek, @ogpeek/react, ogpeek-extension. release-please's built-in node updater handles each "version" field automatically. - Drop the linked-versions plugin and separate-pull-requests flag — both unnecessary in single-package mode (there's only one component to coordinate). - .release-please-manifest.json: collapse the two per-package entries into a single "." entry at "0.5.0" — matching ogpeek + @ogpeek/react on npm and the existing v0.5.0 tag. - .github/workflows/release-please.yml: - Replace the four per-package outputs with a single release_created + tag_name pair, both keyed against the "." path. - Gate publish-ogpeek and publish-ogpeek-react on the same single output so they always fire together with the new umbrella release. - Add publish-ogpeek-extension that runs alongside the other two: builds the workspace libs explicitly (no reliance on the website-anchored libs:build script), runs build:chrome + the zip script directly to avoid double-building libs through package:chrome, and uploads dist/ogpeek-chrome.zip to the GitHub Release with --clobber for re-run idempotency. This job uses GITHUB_TOKEN only (contents: write) — no npm credentials, no OIDC. Trade-offs ---------- - All three packages always share a version going forward. A fix in one package bumps all three (phantom bump for the others on npm / on a new GitHub Release). Acceptable because the three move together anyway. - Per-package CHANGELOG.md files (packages/ogpeek/CHANGELOG.md, packages/ogpeek-react/CHANGELOG.md) keep their historical entries but won't get new ones — the next release writes only to the root CHANGELOG.md. That's intentional: the umbrella release notes are the new source of truth, scoped per-package via Conventional Commit scopes (feat(ogpeek-extension), fix(ogpeek-react), etc.) inside each entry. - Existing per-component tags (ogpeek-react-v0.5.0) become orphaned but harmless — git keeps them; GitHub keeps the matching Release. Verification after merge ------------------------ This commit is a chore (no Conventional Commit type that triggers a bump), so the release-please run on push will not propose a release. The next feat/fix that lands on main will produce the first single-package-mode release PR — expected: - One "chore: release main" PR with version bumped to 0.5.1 / 0.6.0 / 1.0.0 (per the bump rules) on the root CHANGELOG. - All three package.jsons updated to the new version via extra-files. - Merging cuts a single "vX.Y.Z" tag + a single GitHub Release. - Three publish jobs fire from the one release_created event: publish-ogpeek (npm), publish-ogpeek-react (npm), publish-ogpeek-extension (GitHub Release zip upload). Supersedes #32, which approached the extension-tracking problem within the existing per-package monorepo structure. https://claude.ai/code/session_0162rG86ukDFiBZfqgEADYfp
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
Wire
packages/ogpeek-extension(added in #28, dark-theme variants in #30) into release-please as a tracked package, linked toogpeekso the engine and the extension cut releases at the same version going forward. Distribution stays GitHub-Release-only — no npm — so the publish job builds the Chrome zip and attaches it to the matching GitHub Release.This finishes the migration of all three workspace packages onto the release-please pipeline that was kicked off by #29 + #31 (where
ogpeekand@ogpeek/reactcut their first coordinated0.5.0release).Changes
release-please-config.jsonpackages/ogpeek-extensionentry.component: "ogpeek-extension"+include-component-in-tag: true→ tags areogpeek-extension-vX.Y.Z(never collides withogpeek'svX.Y.Z).linked-versionsplugin (groupName: ogpeek-engine, members:ogpeek+ogpeek-extension).@ogpeek/reactstays out of the group on its own track since its API surface is independent.component: "ogpeek"onogpeek's entry so linked-versions can address it explicitly.include-component-in-tag: falsestays, so the tag format remainsvX.Y.Z— npm publish path unchanged..release-please-manifest.jsonpackages/ogpeek-extension: "0.0.0"— release-please's bootstrap placeholder. Combined with theRelease-As: 0.5.0footer below, this pins the firstogpeek-extensionrelease to0.5.0, aligning with the just-cutogpeek 0.5.0/@ogpeek/react 0.5.0baseline.packages/ogpeek-extension/CHANGELOG.md(new)Release-Asactually applies to the extension package — without a file underpackages/ogpeek-extension/in the diff, the footer would have no association to scope it to (as we hit on fix(ogpeek-react): reset release-please manifest to bootstrap state #29/chore: release main #31, whereRelease-As: 0.5.0was silently dropped because the commit only touched the manifest)..github/workflows/release-please.ymlextension_release_created/extension_tag_nameoutputs from therelease-pleasejob (matching existingogpeek_*/react_*shape).publish-ogpeek-extensionjob — gated onextension_release_created == 'true', checks out the extension tag, builds workspace libs (extension bundlesogpeek+@ogpeek/react), runs the existingpackage:chromescript →dist/ogpeek-chrome.zip, and uploads to the matching GitHub Release viagh release upload.GITHUB_TOKENonly (contents: write) — no npm credentials, no OIDC dance, since nothing in this path touches npm.The extension's
package.jsonkeeps"version": "0.0.0"+"private": true. release-please will write0.5.0in the next release PR's commit before merge, andprivate: trueblocks accidentalpnpm publishfrom leaking the extension to npm regardless of the version on disk.Test plan
mainopens a freshchore: release mainPR. Expected content:ogpeekstays at0.5.0(no new commits since the last cut).@ogpeek/reactstays at0.5.0(no new commits since the last cut).ogpeek-extensioncuts0.5.0from theRelease-Asfooter in this commit, listing feat(extension): cross-browser MV3 extension (Chrome v1) #28 and feat(extension): dark-theme toolbar icon variants #30 in its CHANGELOG.ogpeek-extension-v0.5.0tag + a GitHub Release.publish-ogpeek-extensionjob runs, buildsdist/ogpeek-chrome.zip, and the zip is attached to the GitHub Release as a downloadable asset.ogpeek(the linked-versions plugin should be a no-op for ogpeek when the highest proposed version in the group already equals ogpeek's current version0.5.0).@ogpeek/reactis unaffected by this PR — same0.5.0on npm, no new release PR for it.Going forward
feat:commit affectingpackages/ogpeek/orpackages/ogpeek-extension/will bump both to the same next version (e.g.,0.6.0) via the linked-versions plugin. That cuts bothv0.6.0(ogpeek tag) andogpeek-extension-v0.6.0simultaneously, with ogpeek hitting npm and the extension getting a new zip on its release.ogpeek↔ogpeek-extensionthis is acceptable since the extension is just a packaging surface around the engine; for@ogpeek/react, the cost would have been higher (independent React API), which is why it stays out of the group.Korean
요약
#28에서 들어오고 #30에서 다크 테마 아이콘이 추가된
packages/ogpeek-extension을 release-please의 추적 대상으로 등록하고,linked-versions플러그인으로ogpeek과 같은 버전을 공유하도록 묶음. 배포는 npm이 아니라 GitHub Releases에 Chrome zip을 첨부하는 방식.#29 + #31로 시작된 release-please 파이프라인 이전 작업이 이걸로 마무리 — 세 워크스페이스 패키지가 모두 같은 시점 (
0.5.0) 에서 같은 흐름을 탑니다.핵심 변경
release-please-config.json: extension 패키지 등록 (include-component-in-tag: true로 태그 충돌 방지) +linked-versions플러그인 (ogpeek + ogpeek-extension만, ogpeek-react는 독립 유지) + ogpeek에component: "ogpeek"명시 (plugin이 패키지 식별할 수 있도록)..release-please-manifest.json: extension 항목0.0.0으로 추가, 아래Release-As: 0.5.0footer로 첫 릴리즈를 0.5.0으로 못박음.packages/ogpeek-extension/CHANGELOG.md: 빈 stub 추가 — release-please가 첫 릴리즈에 채울 자리 + 이 커밋이 extension 패키지 경로에 anchor되도록 (fix(ogpeek-react): reset release-please manifest to bootstrap state #29/#31에서 manifest만 건드려서 Release-As가 무시됐던 경험 학습)..github/workflows/release-please.yml:publish-ogpeek-extensionjob 추가 — 빌드 + zip +gh release upload. npm 안 거치므로 OIDC 시크릿 불필요,GITHUB_TOKEN만으로 동작.extension
package.json은version: "0.0.0"+private: true유지. release-please가 release PR에서 0.5.0으로 다시 써주고,private: true가 npm 실수배포 방어선.테스트 계획
mainpush에서chore: release mainPR이 새로 열리고ogpeek-extension 0.5.0만 cut (ogpeek/react는 변동 없음).ogpeek-extension-v0.5.0태그 + GitHub Release 생성 →publish-ogpeek-extensionjob이 zip 빌드해서 release에 첨부.앞으로
ogpeek또는ogpeek-extension한쪽에feat:들어오면 둘 다 같은 다음 버전 (예:0.6.0)으로 bump — 한쪽은 phantom일 수 있지만 extension은 엔진 패키징 surface라 비용이 낮음.@ogpeek/react는 그룹 밖에 있으니 React API 자체 변경에만 반응.https://claude.ai/code/session_0162rG86ukDFiBZfqgEADYfp
Generated by Claude Code