endolinbot
ae2949253c
Copied from kriscendobot/garden skills/yarn-lock-separate-commit/SKILL.md (only that file) at commit f6fd8db6abe012366aa4c843874c07adae46e7f7: https://github.com/kriscendobot/garden/blob/f6fd8db6abe012366aa4c843874c07adae46e7f7/skills/yarn-lock-separate-commit/SKILL.md
52 lines
2.6 KiB
Markdown
52 lines
2.6 KiB
Markdown
---
|
|
created: 2026-05-13
|
|
updated: 2026-05-17
|
|
author: liaison, gardener
|
|
---
|
|
|
|
# Skill: yarn-lock-separate-commit
|
|
|
|
Adopted from `references/endo-but-for-bots/skills/yarn-lock-separate-commit.md`.
|
|
|
|
Every change that touches `yarn.lock` ships in its own commit, separate from the `package.json` change that caused the update, with the message `chore: Update yarn.lock`.
|
|
|
|
## Why
|
|
|
|
A separate lockfile commit can be dropped and regenerated cleanly on rebase. A combined commit turns lockfile churn into merge conflicts that have to be resolved by re-running `yarn install` and hand-stitching, which is error-prone and pollutes history.
|
|
|
|
## Procedure
|
|
|
|
After making the dep change in `package.json`:
|
|
|
|
```sh
|
|
git add packages/foo/package.json
|
|
git commit -m "feat(foo): add bar dependency (#NNNN)"
|
|
|
|
npx corepack yarn install
|
|
git add yarn.lock
|
|
git commit -m "chore: Update yarn.lock"
|
|
```
|
|
|
|
When force-pushing a rebased branch, the order of the two commits matters: put the lockfile commit *after* the package.json commit, so a reviewer dropping the lockfile commit lands at a still-coherent state.
|
|
|
|
## Pitfalls
|
|
|
|
- **`git commit --amend` on the package.json commit silently drags the lockfile in if staged.** Stage and commit the lockfile last.
|
|
- **Accidental combining.** If caught on review, `git reset HEAD~1`, re-stage selectively, and recommit as two.
|
|
- **Package renames invalidate the lockfile.** Renaming a workspace's directory or `package.json:name` changes the workspace key (`"@scope/<name>@workspace:packages/<dir>"`) inside `yarn.lock`. Still ships in its own `chore: Update yarn.lock` commit, regenerated by re-running `npx corepack yarn install` after all renames are in place. Don't hand-edit the workspace key; the install produces the canonical form.
|
|
|
|
## Notes from the field
|
|
|
|
- _2026-05-13_: adopted from the reference. Session example from PR 71 lives in the journal, not here.
|
|
- _2026-05-17_: a PR carrying `chore: Update yarn.lock` typically conflicts on the lockfile when rebased onto a moved base (any other PR that touched dependencies has landed in the interim). The workflow that resolved it cleanly: skip the old lockfile commit during rebase, apply any review-feedback fixes on top, then regenerate the lockfile against the new base as its own commit. Source: PR #238 fixer, `journal/entries/2026/05/17/200805Z-message-fixer-3e9fd0.md`.
|
|
|
|
```sh
|
|
git rebase origin/<base>
|
|
# conflict on yarn.lock
|
|
git rebase --skip # drop the old lockfile commit
|
|
# apply review-feedback fixes on top
|
|
npx corepack yarn install # regenerate lockfile against new base
|
|
git add yarn.lock
|
|
git commit -m "chore: Update yarn.lock"
|
|
```
|