Repository navigation
feat: release a bundling package as its bundled siblings' release type - #81
Conversation
…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.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
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.
|
@codex security review |
🛡️ Codex Security ReviewSecurity review completed. No security issues were found in this pull request. Reviewed commit: Only the user who started this review can view the report in Codex. ℹ️ About Codex security reviews in GitHubThis is an experimental Codex feature. Security reviews are triggered when:
Once complete, Codex will leave suggestions, or a comment if no findings are found. |
|
@codex security review |
|
🎉 This PR is included in version 3.2.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
🛡️ Codex Security ReviewSecurity review completed. No security issues were found in this pull request. Reviewed commit: Only the user who started this review can view the report in Codex. ℹ️ About Codex security reviews in GitHubThis is an experimental Codex feature. Security reviews are triggered when:
Once complete, Codex will leave suggestions, or a comment if no findings are found. |
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
bundlingPackagesoption: a public package named there releases as at least the highest release type among the releases of its workspacedevDependenciesin the run, so afixin a bundled sibling gives a patch, afeata 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 setbundlingPackages: ['process-graph'].It is an option rather than the default because a workspace
devDependenciesentry 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 afeatin a test helper into a minor release of the package that uses it. Edges independencies,peerDependenciesandoptionalDependencieskeep 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-Typeline 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'sbundlingPackagesarray or thereleaseWorkspace()option.releasePackageAcrossBranchMovesis 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