Context
While fixing #310's changesets/workspace bug (root package unpublishable when workspaces is added — see #318 and its follow-up restructure PR), we confirmed that the currently pinned @changesets/cli@^2.29.7 depends on @manypkg/get-packages@^1.1.3, an old version whose getPackages() detects monorepo "tool" type purely from the presence of a workspaces array in package.json — it has no NpmTool implementation at all and never inspects package-lock.json. Any npm-workspaces repo (including this one) is therefore internally labeled tool: "yarn" by changesets, even though every install/build/publish command in this repo is npm.
This is currently harmless: the tool value only affects git tag naming (@pkg/name@version for tool !== "root", vs. v<version> for tool === "root"), and yarn/npm produce the same tag format there. Verified in a scratch install:
$ node -e "require('@manypkg/get-packages').getPackages(process.cwd()).then(r=>console.log(r.tool))"
yarn
Proposed fix
Upgrade @changesets/cli to 3.x, which bundles @manypkg/get-packages@^3.x / @manypkg/tools@^2.x — this version has a real NpmTool that detects package-lock.json + workspaces and reports tool: "npm".
This is a breaking upgrade, not a patch bump — needs its own verification pass:
- ESM-only package (repo is already
"type": "module", so likely fine, but must verify)
.changeset/pre.json auto-migrates to a new .changeset/pre/ directory structure on first changeset version / changeset status run
- Private packages are no longer versioned by default (
privatePackages config now defaults differently)
changeset tag renamed to changeset git-tag
- New
engines floor: npm ≥10.9.0, pnpm ≥10.0.0, yarn ≥4.5.2 — CI's .nvmrc (Node v22.21.1) ships npm 10.9.4, which clears this, but should be double-checked against .github/workflows/release.yml's npm install -g npm@latest step
Trigger for pickup
Should be picked up once the #310/#311 workspace-root-restructure PR (moving @uswds/elements into packages/elements/) has merged, since that PR is what makes workspaces a permanent, load-bearing part of the repo's package.json — this upgrade is cosmetic (correctness of internal tool detection) but worth doing before the repo depends on this behavior for anything more than tag naming.
Scope
Not blocking any current release — verified the fix for the actual publishing bug (root package unpublishable) does not require this upgrade.
Context
While fixing #310's changesets/workspace bug (root package unpublishable when
workspacesis added — see #318 and its follow-up restructure PR), we confirmed that the currently pinned@changesets/cli@^2.29.7depends on@manypkg/get-packages@^1.1.3, an old version whosegetPackages()detects monorepo "tool" type purely from the presence of aworkspacesarray inpackage.json— it has noNpmToolimplementation at all and never inspectspackage-lock.json. Any npm-workspaces repo (including this one) is therefore internally labeledtool: "yarn"by changesets, even though every install/build/publish command in this repo is npm.This is currently harmless: the
toolvalue only affects git tag naming (@pkg/name@versionfortool !== "root", vs.v<version>fortool === "root"), and yarn/npm produce the same tag format there. Verified in a scratch install:Proposed fix
Upgrade
@changesets/clito3.x, which bundles@manypkg/get-packages@^3.x/@manypkg/tools@^2.x— this version has a realNpmToolthat detectspackage-lock.json+workspacesand reportstool: "npm".This is a breaking upgrade, not a patch bump — needs its own verification pass:
"type": "module", so likely fine, but must verify).changeset/pre.jsonauto-migrates to a new.changeset/pre/directory structure on firstchangeset version/changeset statusrunprivatePackagesconfig now defaults differently)changeset tagrenamed tochangeset git-tagenginesfloor: npm ≥10.9.0, pnpm ≥10.0.0, yarn ≥4.5.2 — CI's.nvmrc(Node v22.21.1) ships npm 10.9.4, which clears this, but should be double-checked against.github/workflows/release.yml'snpm install -g npm@lateststepTrigger for pickup
Should be picked up once the #310/#311 workspace-root-restructure PR (moving
@uswds/elementsintopackages/elements/) has merged, since that PR is what makesworkspacesa permanent, load-bearing part of the repo'spackage.json— this upgrade is cosmetic (correctness of internal tool detection) but worth doing before the repo depends on this behavior for anything more than tag naming.Scope
Not blocking any current release — verified the fix for the actual publishing bug (root package unpublishable) does not require this upgrade.