pnpm reads and validates `pnpm-workspace.yaml` before it switches to the
version `packageManager` pins, so a hard error at load time fires in the
pnpm that is on its way out. An unknown top-level key already accounts
for this: it is collected as a key issue and reported once the switch is
settled, and only by the pnpm that goes on to act on the file. A `tasks`
entry's unknown field did not, which left a project unable to adopt a
task setting its own pin understands until every contributor's global
pnpm was new enough to parse it.
Unknown task fields now travel that same path. pnpm 11 reached the same
conclusion for its own reader in pnpm/pnpm#15075; this is the half of
the problem that lives in the version the settings belong to.
A reported field is taken out of the settings, and an entry that carried
nothing else goes with it: a setting pnpm says it ignored must not come
back out of `pnpm config`, and an entry standing on one would declare an
empty dependency list where a task with no entry keeps its default
`^<name>` ordering. A report names only the first few fields and counts
the rest, because each path repeats the name of its task and a file
declaring one long name and many fields would otherwise render far more
text than it holds.
The other task checks are wrong in any version and still fail the load.
The global `config.yaml` drops its whole `tasks` section as
workspace-only, so a field inside one there never set anything and is
simply ignored with it.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
