feat: implement internal dependency synchronization and changelog generation

[frontegg-david]

Summary by CodeRabbit

• Chores
  • Released Enclave VM v1.0.1 with an updated dependency.
  • Improved release automation: more reliable SHA handling, generated release body for GitHub Releases, and enhanced changelog outputs.
• New Features
  • Added automatic internal dependency synchronization that may apply patch bumps to affected libraries and records dependency updates.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Adds a two-pass internal dependency synchronization step to the release workflow, configures Nx SHAs and generates a release body from published package.json files, and bumps libs/enclave-vm from 1.0.0 to 1.0.1 with an ast-guard dependency update.

Changes

Cohort / File(s)	Summary
Release workflow updates .github/workflows/create-release-branch.yml, .github/workflows/publish-on-next-close.yml	create-release-branch.yml: Adds an internalVersions map, helpers to patch semantic versions and detect exact pins, records per-project newVersion on first pass, then a second pass that updates publishable libs' internal dependency pins and auto-patches downstream libs when needed, writing updated package.json files and updating bumpedProjects/maxVersion. publish-on-next-close.yml: Adds Nx SHA setup step and a "Generate release body" step that builds a release body from libs/*/package.json (or a fallback message) and supplies it to the GitHub Release action.
Package manifest change libs/enclave-vm/package.json	version bumped from 1.0.0 to 1.0.1; dependencies.ast-guard updated from 1.0.0 to 1.1.0.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20–25 minutes

• Review the multi-pass dependency-synchronization logic in .github/workflows/create-release-branch.yml (internalVersions bookkeeping, isExactVersion checks, correct application of patch bumps, and writing package.json).
• Verify publish-on-next-close flow: Nx SHA step placement, the release body generation logic (file paths, package discovery, fallback), and consumption by the GitHub Release action.
• Confirm bumpedProjects and maxVersion aggregation and Codex/metrics outputs reflect the new internalVersions behavior.

Poem

🐰 I hopped through bumps and patched each thread,

versions tracked, then tidy changes spread.
From libs to release, a neat little tune,
package bodies ready — soon, soon, soon! ✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately reflects the main changes: it describes the implementation of internal dependency synchronization (visible in create-release-branch.yml) and changelog generation (visible in publish-on-next-close.yml).
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix-workflow

---

📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ad1cbba and b27c626.

📒 Files selected for processing (1)

• .github/workflows/create-release-branch.yml (3 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: build

🔇 Additional comments (2)

.github/workflows/create-release-branch.yml (2)

255-270: ✓ Range specifier issue from past review appears addressed.

The isExactVersion() helper now correctly gates dependency updates to only exact-pinned versions (line 363). Dependencies with range specifiers (e.g., "^1.0.0", "~1.0.0") will not be updated, preserving semantic versioning flexibility for those that choose ranges over exact pins. This resolves the past critical concern about silently converting ranges to exact pins.

---

340-389: Verify dependency type coverage for internal dep synchronization.

The second pass (lines 340–389) only synchronizes versions for pkg.dependencies (line 361). If internal packages are also declared in devDependencies, peerDependencies, or optionalDependencies, they will not be synchronized across the monorepo.

Is it intentional to exclude devDependencies and other dependency types from synchronization, or should the code iterate through all dependency fields? If internal packages are used in multiple dependency types, you may need to extend the loop to cover all relevant fields:

const depTypes = ['dependencies', 'devDependencies', 'peerDependencies', 'optionalDependencies'];
for (const depType of depTypes) {
  if (pkg[depType]) {
    for (const [dep, version] of Object.entries(pkg[depType])) {
      if (internalVersions[dep] && isExactVersion(version) && version !== internalVersions[dep]) {
        pkg[depType][dep] = internalVersions[dep];
        modified = true;
        needsBump = true;
        console.error(`Updated ${libName} ${depType}.${dep} to ${internalVersions[dep]}`);
      }
    }
  }
}

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

.github/workflows/create-release-branch.yml (1)

258-262: Add validation to bumpPatch to handle unexpected version formats.

The bumpPatch function assumes semantic versioning format but does not validate the input. If a malformed version (e.g., "1.0", "1.0.0-rc.1", or unexpected formats) reaches this function, the increment may behave unexpectedly or produce invalid versions.

Apply this diff to add basic validation:

  function bumpPatch(version) {
    const parts = version.split('.');
+   if (parts.length < 3 || isNaN(parseInt(parts[2], 10))) {
+     throw new Error('Invalid semantic version: ' + version);
+   }
    parts[2] = String(parseInt(parts[2], 10) + 1);
    return parts.join('.');
  }

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 7b6e433 and ad1cbba.

📒 Files selected for processing (3)

• .github/workflows/create-release-branch.yml (3 hunks)
• .github/workflows/publish-on-next-close.yml (2 hunks)
• libs/enclave-vm/package.json (2 hunks)

🧰 Additional context used

📓 Path-based instructions (1)

libs/**

⚙️ CodeRabbit configuration file

libs/**: Contains publishable SDK libraries. Review for API correctness, breaking changes, and consistency with docs. When public APIs change, ensure there is a matching docs/draft/docs/** update (not direct edits under docs/docs/**).

Files:

• libs/enclave-vm/package.json

🔇 Additional comments (4)

libs/enclave-vm/package.json (1)

3-3: Verify justification for patch bump when dependency is updated.

The version bump to 1.0.1 and ast-guard dependency update to 1.1.0 appear to be driven by the new internal dependency-synchronization workflow. Confirm that:

1. The patch bump is semantically justified (e.g., not just a derived bump from dependency updates that are themselves backward-compatible)
2. The ast-guard 1.1.0 update introduces no breaking changes to this library's public API

Also applies to: 39-39

.github/workflows/publish-on-next-close.yml (2)

66-67: ✓ Nx SHAs setup is correctly placed.

The Set Nx SHAs step is appropriately positioned before computing affected projects, enabling the --affected flag to function correctly in the release workflow.

---

229-263: Verify GitHub Release action behavior with both body_path and generate_release_notes.

The release body generation logic is sound—it correctly reads package versions, constructs npm links, and writes to a temporary file for multiline support. However, when using both body_path and generate_release_notes: true together, verify the interaction:

• Does softprops/action-gh-release concatenate the provided body with auto-generated notes, or does body_path take full precedence?
• If concatenation occurs, will the release body have the expected structure?

This affects how release notes appear to end users, so confirm the behavior aligns with your expectations.

.github/workflows/create-release-branch.yml (1)

332-380: Two-pass dependency synchronization logic is sound overall, with good safeguards against double-bumping.

The second pass correctly:

• Identifies all publishable libraries
• Checks for dependencies that reference bumped packages
• Avoids double-bumping via !internalVersions[libName] check (line 364)
• Updates internalVersions and maxVersion consistently
• Writes only modified packages back to disk
• Gracefully handles execSync failure with a warning

The approach enables transitive dependency updates—if lib A depends on bumped lib B, lib A gets a patch bump and can then propagate downstream.

However, this is conditional on resolving the range-to-exact version conversion issue identified above.