Skip to content

feat: release a bundling package as its bundled siblings' release type - #81

Merged
Mearman merged 8 commits into
mainfrom
feat/80-bundled-release-type
Oct 11, 2026
Merged

Mearman merged 8 commits into
mainfrom
feat/80-bundled-release-type

Conversation

@Mearman

@Mearman Mearman commented Oct 11, 2026

Copy link
Copy Markdown
Member

A package that inlines its private siblings into its own build gets only a patch when one of them releases, whatever the sibling's change was. This adds a bundlingPackages option: a public package named there releases as at least the highest release type among the releases of its workspace devDependencies in the run, so a fix in a bundled sibling gives a patch, a feat a minor and a breaking change a major, and the package's own releasable commits are raised to that type when it is higher. ExaDev/process-graph#41 is the consumer: it would set bundlingPackages: ['process-graph'].

It is an option rather than the default because a workspace devDependencies entry is not bundled in general. A public package's test helper or lint config in the same workspace is a devDependency whose changes never reach its consumers, and making the default follow devDependencies would turn a feat in a test helper into a minor release of the package that uses it. Edges in dependencies, peerDependencies and optionalDependencies keep the forced patch whether or not the option is set, since consumers install those siblings themselves.

A bundled sibling's type also reaches the bundling package through private packages that depend on it at run time, so a private package that the bundling package does not list directly still counts. Private packages keep their own version bumps, the forced patch included, so their versions and tags are what they were before, and they are still never published.

Each released package now records the release type it ships on every bump of its dependents and in a new Bumped-Workspace-Dependency-Release-Type line in the bump commit's trailer, so a run that resumes after a partial push recovers the type. Bump commits written before the line existed parse as before and count as the patch they always forced.

The option works under both commit strategies and with gatePublish, and is set with --bundling-package <name> (repeatable), a config file's bundlingPackages array or the releaseWorkspace() option. releasePackageAcrossBranchMoves is now generic over the attempt it passes through, so the release loop can carry the release type without widening that loop's type.

Fixes #80

…ched

The branch-move loop only reads whether an attempt released, so it is now
generic over the attempt's shape instead of fixing it to a version and an
opaque result. Callers can report more about a release without widening
the loop's own type.
resolveBundledDependencies reads the bundlingPackages option against the
dependency graph: a named public package bundles every workspace sibling in
its devDependencies, and a private package carries its private run-time
siblings to whatever bundles it. Unknown and private names are rejected.
A package named in bundlingPackages now releases as at least the highest
release type among the releases of its workspace devDependencies, instead
of the patch any dependency bump forces: a fix in a bundled sibling gives a
patch, a feat a minor, a breaking change a major, and the package's own
releasable commits are raised to that type when it is higher. Ordinary
dependencies, peerDependencies and optionalDependencies edges keep the
forced patch, and private packages keep their own version bumps and tags.

Each released package records the release type it ships, raised through the
private run-time siblings it carries, on every bump of its dependents and in
the bump commit's new Bumped-Workspace-Dependency-Release-Type trailer, so a
run that resumes after a partial push reaches the same type. Bump commits
written before the trailer line existed count as the patch they forced.

The option applies to the per-package, single-commit and gated paths and is
off unless set, since a workspace devDependency is not bundled in general.

Fixes #80
--bundling-package <name> names a bundling package and repeats for several;
a config file's bundlingPackages array does the same, and the flag wins
when both are given.
Adds a section on bundlingPackages, the CLI flag, the new trailer field and
a pointer from the forced-patch paragraph to when a patch is the wrong
answer.
buildDependencyGraph gives every package an entry, so a missing one is an
internal error for mustGet to report, not an empty list.
@Mearman
Mearman marked this pull request as ready for review October 11, 2026 05:01
@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Oct 11, 2026 •

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
🔒 Security Review ✅ Completed 2026-10-11T05:17:17.191317Z 0e25b79 Manual request
ℹ️ 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

…ptional

Both are exported, so an embedder that builds its own scope or bump source
keeps compiling: an omitted bundled scope bundles nothing, and a bump with
no release type counts as the patch it always forced.
@Mearman

Mearman commented Oct 11, 2026

Copy link
Copy Markdown
Member Author

@codex security review

@chatgpt-codex-connector

Copy link
Copy Markdown

🛡️ Codex Security Review

Security review completed. No security issues were found in this pull request.

Reviewed commit: 0e25b79d86

View security finding report

Only the user who started this review can view the report in Codex.

ℹ️ About Codex security reviews in GitHub

This is an experimental Codex feature. Security reviews are triggered when:

  • You comment "@codex security review"
  • A regular code review gets triggered (for example, "@codex review" or when a PR is opened), and you’re opted in so security review runs alongside code review

Once complete, Codex will leave suggestions, or a comment if no findings are found.

@Mearman

Mearman commented Oct 11, 2026

Copy link
Copy Markdown
Member Author

@codex security review

@Mearman
Mearman merged commit 91281f6 into main Oct 11, 2026
@Mearman
Mearman deleted the feat/80-bundled-release-type branch October 11, 2026 05:13
@github-actions

Copy link
Copy Markdown

🎉 This PR is included in version 3.2.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

@chatgpt-codex-connector

Copy link
Copy Markdown

🛡️ Codex Security Review

Security review completed. No security issues were found in this pull request.

Reviewed commit: 0e25b79d86

View security finding report

Only the user who started this review can view the report in Codex.

ℹ️ About Codex security reviews in GitHub

This is an experimental Codex feature. Security reviews are triggered when:

  • You comment "@codex security review"
  • A regular code review gets triggered (for example, "@codex review" or when a PR is opened), and you’re opted in so security review runs alongside code review

Once complete, Codex will leave suggestions, or a comment if no findings are found.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

A dependent that bundles a sibling only ever gets a patch from the sibling's release

1 participant