pnpm version: tagVersionPrefix from pnpm-workspace.yaml silently ignored in v12 (honored in v11)

Summary

pnpm version in v12 ignores tagVersionPrefix from pnpm-workspace.yaml. v11 honors it. Same repo, same config, only the binary differs — every release tag silently gains a v prefix.

I believe this is the version-command half of the cluster described in #13542, which already names tag_version_prefix as flag-only in pacquet. Filing it separately because that issue is scoped to publish/auth, and this one has a user-visible symptom plus two findings I did not see covered there (see "Two things that make it hard to notice").

Reproduction

mkdir t && cd t && git init
echo '{"name":"t","version":"1.0.0","private":true}' > package.json
echo 'tagVersionPrefix: ""' > pnpm-workspace.yaml
git add -A && git commit -m init
pnpm version minor
git tag

pnpm version minor --tag-version-prefix= produces 1.1.0 on 12.x, so only the config path is affected.

Everything else that does not work on 12.4.1

Tested individually, each producing v1.1.0:

• pnpm-workspace.yaml: tagVersionPrefix: ""
• pnpm-workspace.yaml: tag-version-prefix: ""
• pnpm-workspace.yaml: nested under pnpm:
• package.json: "pnpm": { "tagVersionPrefix": "" }
• .npmrc: tag-version-prefix= (and with a non-empty value such as rel-)
• env PNPM_CONFIG_TAG_VERSION_PREFIX=
• env npm_config_tag_version_prefix=

The PNPM_CONFIG_* case seems worth singling out: #13542 states that the TS CLI resolves these settings through yaml, config.yaml, PNPM_CONFIG_* and flags. Here the env var is dropped too, so there is no escape hatch short of the flag.

Two things that make it hard to notice

1. pnpm config set writes the setting and it has no effect.

pnpm config set tag-version-prefix "" --location=project
# writes  tagVersionPrefix: ''  into pnpm-workspace.yaml
pnpm version minor
# -> v1.1.0

The command accepts the setting, persists it in the documented location, reports success — and the value is never read.

2. No unrecognized-setting error, even when packageManager pins a satisfied version.

v12 reports unrecognized pnpm-workspace.yaml settings and fails with ERR_PNPM_UNRECOGNIZED_WORKSPACE_SETTINGS when the project pins a pnpm version the running pnpm satisfies. In a repo with "packageManager": "[email protected]" running 12.4.1, tagVersionPrefix triggers neither — pnpm install completes cleanly. The key passes validation as a known setting while being unused, so the safety net built exactly for this does not catch it.

Between the two, a config that worked for dozens of releases stops working with no signal anywhere.

Question

Is dropping the config chain for version intended, or is it an unfinished part of the port?

The docs read as if the flag were the only surface that ever existed: pnpm.io/cli/version documents --tag-version-prefix with no mention of a config key, and the versioning settings page lists no tag-prefix setting. If flag-only is the intended end state, it would help to say so — the setting still exists in the config schema, pnpm config set still writes it, and v11 still honors it, which together read as "supported".

If it is unfinished, is it tracked by #13542's sweep, or does the version command need its own?

Environment

• pnpm 12.4.1 and 12.4.2, both via mise, macOS arm64 (Darwin 27.0.0)
• working baseline: pnpm 11.5.2