fix: Pin packageManager so Corepack can resolve devEngines

[razor-x]

Dependabot has opened no npm update PRs since 2026-07-28. Its update runs have been failing the whole time:

| @seamapi/types | dependency_file_not_resolvable | {
|                |                                |   "message": "Invalid package manager specification in package.json.
|                |                                |    The packageManager field must specify a valid semver version" }

@seamapi/types is named only because it is the dependency Dependabot was attempting to update — the allow rule in .github/dependabot.yml limits updates to @seamapi/*, so it is the only name that can appear there. The error is dependency_file_not_resolvable: the manifest never parsed, so no resolution was attempted.

Cause

Corepack rejects a range in devEngines.packageManager.version when no top-level packageManager field is present. Reproduced against this repo's package.json verbatim:

$ corepack npm --version
Invalid package manager specification in package.json (npm@^11.0.0 || ^10.9.4); expected a semver version

Dependabot runs npm through Corepack in order to respect the packageManager setting, so that parse failure aborts the run before any dependency work happens. It matches on Corepack's message and re-raises it as the error above:

# npm_and_yarn/lib/dependabot/npm_and_yarn/file_updater/npm_lockfile_updater.rb
INVALID_PACKAGE_MANAGER_SPEC = /Invalid package manager specification/
...
if error_message.match?(INVALID_PACKAGE_MANAGER_SPEC)
  msg = "Invalid package manager specification in package.json. " \
        "The packageManager field must specify a valid semver version"
  raise Dependabot::DependencyFileNotResolvable, msg

This is an upstream Corepack bug — nodejs/corepack#729, "added devEngines support breaks updating dependencies", reported by someone hitting it through Dependabot with the same error. The fix, #730, is still open, so there is no Corepack release to upgrade to and a local workaround is required.

devEngines was added in #595, which is also the last commit before Dependabot went quiet.

Change

Adds a top-level packageManager field. Corepack prefers it over devEngines, so the range is never parsed as a version and devEngines is kept as the declared support range.

The pin must satisfy devEngines, or Corepack fails a different way:

$ corepack npm --version   # packageManager: npm@9.9.9
"packageManager" field is set to "npm@9.9.9" which does not match the value
defined in "devEngines.packageManager" for "npm" of "^11.0.0 || ^10.9.4"

npm 11.19.0 is the newest release satisfying both devEngines (^11.0.0 || ^10.9.4) and engines (>=10.9.4). Choosing from the 11.x line rather than 10.9.x also keeps Dependabot's release-age cooldown available, which it skips on npm below 11.10:

# npm_and_yarn/lib/dependabot/npm_and_yarn/helpers.rb
# True when the running npm supports `--min-release-age` (npm 11.10+). Because
# npm runs through Corepack, a repo pinned to an older npm via `packageManager`
# would reject the flag, so the cooldown gate must be skipped for it.

Verification

$ corepack npm --version   # this PR's package.json
11.19.0                    # exit 0

Also verified: plain npm install --package-lock-only succeeds, and removing devEngines entirely would work too — it was rejected because devEngines is the thing worth keeping.

Note this makes Corepack-enabled environments fetch npm 11.19.0. CI is unaffected, as it runs npm ci directly rather than through Corepack.

Rollout

Other repos that received the same devEngines block are broken identically and need the same fix.

The real test is the daily 09:53 UTC Dependabot run after this lands on main — Dependabot reads the default branch, so it cannot be exercised from this branch. @seamapi/types is pinned at 1.1001.0 against 1.1026.0 published, so a bump should appear if resolution succeeds.