基于Lerna与Conventional Commits的Monorepo LTS版本实现问询

Hey there! Great question about setting up long-term support (LTS) versions with Lerna in your monorepo—let me walk you through a practical, production-ready workflow that aligns with your Conventional Commits setup.

1. Create Dedicated LTS Branches for Each Major Version #

First, you’ll need to isolate each major version line that requires LTS into its own branch. For example, if you’re launching 2.x as your new latest version and need to support 1.x long-term:

# Check out the commit/tag corresponding to your stable 1.0.0 release
git checkout master
git checkout -b lts/1.x
# Push the new LTS branch to remote
git push origin lts/1.x

Stick to a consistent naming convention like lts/<major>.x so your team can instantly recognize which branch maps to which support line.

2. Backport Approved Fixes to LTS Branches #

LTS branches should only receive bug fixes, security patches, or non-breaking chore updates—no new features or breaking changes. To port fixes from master to your LTS branch:

• Identify the commit hash of the fix on master (make sure it uses a fix: or chore: Conventional Commit type—avoid anything with feat: or BREAKING CHANGE:).
• Cherry-pick the commit to your LTS branch, preserving the original commit context:

  git checkout lts/1.x
  git cherry-pick -x <commit-hash>
  

• Resolve any merge conflicts if they arise, then finish the cherry-pick with git cherry-pick --continue.
• Push the updated LTS branch to remote: git push origin lts/1.x

3. Version & Publish LTS Packages with Lerna #

Lerna works seamlessly with separate branches to maintain independent version lines. Here’s how to release updates on your LTS branch:

1. Calculate & Bump Versions: Run Lerna’s version command with Conventional Commits support to auto-determine the correct patch version:

   lerna version --conventional-commits --no-push
   

   The --no-push flag lets you review the version changes locally before pushing tags and branch updates. Lerna will bump packages that received fixes (e.g., a@1.0.0 → a@1.0.1) and update dependent packages (like b) to reference the patched version of a.
2. Publish the LTS Release: Once you’ve verified the version changes, publish using the git tags Lerna generated:

   lerna publish from-git
   

   This ensures you only publish the versions associated with the LTS branch, not the latest master versions.

4. Maintain Separate Version Lines #

• Master Branch: Continue developing new features and breaking changes here, publishing major/minor versions (like a@2.0.0, b@2.0.0) as usual.
• LTS Branches: Restrict commits to only critical fixes. Use git hooks (e.g., Husky) to enforce Conventional Commit rules, blocking any feat: or BREAKING CHANGE: commits from being merged into LTS branches.
• CI/CD Integration: Set up your CI pipeline to run tests automatically on LTS branch pushes, and optionally trigger versioning/publishing (if you’re confident in your automated checks).

Example Walkthrough (Matching Your Scenario) #

Let’s map this to your example with a@1.0.0 and b@1.0.0:

1. On master, you make a breaking change to a, commit with BREAKING CHANGE: Rewrite core API, then run lerna version. This bumps a to 2.0.0, updates b’s dependency to ^2.0.0, and publishes b@1.0.1 (or b@2.0.0 if you had to modify b’s code to support a@2.0.0).
2. To set up LTS for 1.x:
   • Cut the lts/1.x branch from the 1.0.0 release commit.
   • When a critical bug fix lands on master (e.g., fix: Resolve memory leak in a), cherry-pick it to lts/1.x.
   • Run lerna version --conventional-commits on lts/1.x: Lerna bumps a to 1.0.1, updates b’s dependency to ^1.0.1, and tags both packages for release.
   • Publish with lerna publish from-git—now users can choose to install a@^1.0.0 (for LTS patches) or a@^2.0.0 (for latest features).

Key Best Practices #

• Document the Workflow: Add clear guidelines to your repo’s CONTRIBUTING.md explaining which fixes belong in LTS branches vs. master.
• Avoid Dependency Bloat: Don’t upgrade non-critical dependencies in LTS branches—keep dependencies locked to versions that are stable and compatible with the LTS line.
• Communicate LTS Support: Let your users know which versions are under LTS support and for how long, so they can plan their upgrades accordingly.

内容的提问来源于stack exchange，提问作者Jure Triglav