fix: conventional-changelog-conventionalcommits version not updated to 10.2.0

[bugcao]

Steps to Reproduce

@commitlint/config-conventional："21.1.0", 升级到 21.2.0 后，conventional-changelog-conventionalcommits的版本没有升级

Current Behavior

No response

Expected Behavior

提交的时候会报错：
node_modules/.pnpm/@commitlint+cli@21.2.0_@types+node@22.20.0_typescript@5.9.3/node_modules/@commitlint/cli/lib/cli.js:142
throw err;
^

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: No "exports" main defined

Affected packages

• cli
• core
• prompt
• config-angular

Possible Solution

No response

Context

No response

commitlint --version

@commitlint/cli@21.2.0

git --version

v21.2.0

node --version

24.18.0

[escapedcat]

Try this (in cooperation with Claude):

Please regenerate your install so the whole @commitlint/* stack reaches 21.2.0:
rm -rf node_modules pnpm-lock.yaml && pnpm install
pnpm ls @commitlint/resolve-extends conventional-changelog-conventionalcommits
@commitlint/resolve-extends should be >= 21.2.0 and conventional-changelog-conventionalcommits should be 10.x. Let us know if it persists after a clean install!

[simPod]

We reproduced this with a clean Yarn 4 PnP install in CI, and it does not appear to be a stale lockfile / partial upgrade issue.

The failing run already had:

• @commitlint/cli@21.2.0
• @commitlint/config-conventional@21.2.0
• @commitlint/resolve-extends@21.2.0
• conventional-changelog-conventionalcommits@10.2.0
• Node 22.17.1
• Yarn 4.17.0

CI runs yarn install --immutable from a clean checkout, then:

yarn run commitlint --from origin/$CI_DEFAULT_BRANCH --to HEAD -V

It still fails under Yarn PnP with:

Error: No "exports" main defined in .../conventional-changelog-conventionalcommits/package.json imported from .../@commitlint/config-conventional/lib/
Require stack:
- .../@commitlint/config-conventional/lib/noop.js

So the requested 21.2.0 / 10.x stack is already present when the failure occurs. Pinning conventional-changelog-conventionalcommits back to 9.3.1 is an effective workaround for us, but 10.2.0 still fails with Yarn PnP.

[simPod]

Follow-up: the least noisy workaround for us was to keep this out of package.json and encode it only in yarn.lock.

We initially used a root package.json resolution:

"resolutions": {
  "conventional-changelog-conventionalcommits": "9.3.1"
}

That fixed commitlint, but Renovate then treated it as an explicit dependency and opened a follow-up MR to update the resolution back to 10.2.0.

What we ended up doing instead is a Yarn lockfile-only descriptor override:

yarn set resolution "conventional-changelog-conventionalcommits@npm:^10.0.0" "npm:9.3.1"

This produces a yarn.lock entry shaped like:

"conventional-changelog-conventionalcommits@npm:^10.0.0":
  version: 9.3.1
  resolution: "conventional-changelog-conventionalcommits@npm:9.3.1"

So @commitlint/config-conventional@21.2.0 can keep requesting conventional-changelog-conventionalcommits@^10.0.0, but Yarn PnP resolves that descriptor to 9.3.1, avoiding the No "exports" main defined failure from 10.2.0.

This passes for us with:

yarn install --immutable
yarn run commitlint --from origin/master --to HEAD -V

Tested in two separate Yarn 4 PnP repositories. This is only a workaround until 10.x works with commitlint under Yarn PnP.

[escapedcat]

Thanks, this helps. Further reply in cooperation with Claude:

Thanks @simPod — the clean PnP repro is really helpful and rules out a lockfile issue.

This is the same Yarn PnP resolution gap we track in #2637 (help wanted): conventional-changelog-conventionalcommits@10 is import-only ESM, and the preset resolver's ESM fallback we added in 21.2.0 finds the entry by walking node_modules — which PnP doesn't have — so it still fails under PnP.

The fix would be to make that fallback PnP-aware (resolve via the PnP API rather than the node_modules tree), in @commitlint/resolve-extends.
A PR would be very welcome! Until then your yarn set resolution … 9.3.1 pin is the right workaround.