pnpm dependency update 2026-08-17

[commercelayer-ci]

Dependency update

Closes #207
Branch: chore/deps-update-202608171718
Based on stable: v6.9.7
Prerelease tag: v6.9.8-auto-deps-202608171719.0
Node.js: 20.x
pnpm: 10.x

Automated dependency update via pnpm. Review the dependency diff and validation output before merging.

Dependency update results

• Check: success
• Build: success
• Test: failure

Test output

Semver bump log

No semver updates found.

Audit log

No known vulnerabilities found

Major updates log not updated

package.json
  @commercelayer/sdk           ^6.58.0  →  ^7.12.1
  @oclif/core                  ^3.27.0  →  ^4.13.5
  @oclif/test                  ^3.2.15  →  ^4.1.22
  @semantic-release/changelog   ^6.0.3  →   ^7.0.0
  @semantic-release/git        ^10.0.1  →  ^11.0.1
  @types/configstore            ^4.0.0  →   ^6.0.2
  @types/inquirer              ^8.2.13  →  ^9.0.10
  @types/node                  ^25.9.5  →  ^26.2.0
  @types/update-notifier        ^5.1.0  →   ^6.0.8
  configstore                   ^5.0.1  →   ^8.0.0
  inquirer                      ^8.2.7  →  ^14.0.2
  mocha                        ^10.8.2  →  ^11.8.0
  typescript                    ^5.9.3  →   ^7.0.2

[pviti]

Closing: this PR does not carry any actionable change.

The diff is limited to pnpm-lock.yaml and consists of:

1. three transitive packages bumped to releases published within the last 24 hours — baseline-browser-mapping@2.11.15, electron-to-chromium@1.5.408 and json-with-bigint@3.5.12 — which is exactly what makes the Release job fail on Install dependencies with ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION;
2. cosmetic churn removing the (supports-color@8.1.1) peer suffix from a dozen entries.

No direct dependency updates and no security fixes: those already landed on main with #210, which also closed #207. main currently resolves those three packages to the immediately previous, policy-compliant versions (2.11.14 / 1.5.407 / 3.5.11).

The next scheduled dependency update will produce a compliant lockfile once those releases age past the minimumReleaseAge cutoff. If this keeps recurring, the update workflow should resolve with the same minimumReleaseAge policy that the verification step enforces, otherwise it will keep generating lockfiles that the supply-chain gate rejects.