It is safe to remove the field, but there is a reproducibility tradeoff worth making explicit.

packageManager is project tooling metadata. It does not force consumers of a published library to use that manager; it tells compatible tooling which manager and exact version contributors/CI should use. Keeping it plus one matching lockfile makes installs more deterministic. Removing it is reasonable if the repository intentionally tests and supports npm, pnpm, and Yarn rather than choosing one canonical contributor workflow.

For Corepack specifically, the field is written deliberately by corepack use, or automatically when COREPACK_ENABLE_AUTO_PIN=1 and the project has no field. You can check the latter with:

printf "%s\n" "$COREPACK_ENABLE_AUTO_PIN"

If you remove the field but auto-pin remains enabled, it can return on a later package-manager invocation. Also check editor/dev-container/CI setup and the package-manager command itself, since Corepack is not the only possible writer.

I would choose one of these policies:

• Canonical manager: keep packageManager, commit only its matching lockfile, and use that manager in CI.
• Manager-neutral library: remove packageManager, avoid committing contradictory lockfiles, and test every manager you claim to support in CI.

devEngines.packageManager is another option when you want contributor validation and a version range, although ecosystem support is less universal than packageManager.

One current-version detail: Corepack was bundled with Node from 14.19 up to, but not including, Node 25. On newer Node versions it must be installed separately, so disabling the bundled copy is not a future-proof explanation by itself.

Corepack behavior and auto-pin documentation: https://github.com/nodejs/corepack#environment-variables