[Bug: Windows] postinstall emits DEP0190 when launching Lefthook through shell:true

[DebtVC2022]

Environment

• OS: Microsoft Windows 11 Pro 10.0.26200 (build 26200), x64
• Node.js: v24.18.0
• pnpm: 11.19.0
• Git: 2.53.0.windows.2
• Repository commit: 47f943859bef60e4160492346772ded9b24f765a

Reproduction

On an unmodified checkout at the commit above:

pnpm install --frozen-lockfile
node --throw-deprecation scripts/install-lefthook.mjs

The normal postinstall completes but prints DEP0190. The strict command exits with status 1.

Actual behavior

On Windows, runLefthook() launches the node_modules/.bin/lefthook.cmd shim with spawnSync(..., { shell: true }) while also passing ['install', '--force']. Node.js 24 reports that combination as DEP0190; with --throw-deprecation, the installer terminates at scripts/install-lefthook.mjs:560 before Lefthook runs.

Expected behavior

The installer should run lefthook install --force without a command shell, emit no DEP0190 warning, and preserve the existing worktree-local hook installation and rollback behavior.

Root cause

The Windows-specific .cmd launch requires shell: true. Node then concatenates the separately supplied arguments into a shell command without escaping them, which is the deprecated and potentially unsafe pattern identified by DEP0190.

The installed lefthook package already declares a JavaScript bin entry (bin/index.js) that selects and launches its platform-native executable, so the package-manager shim is unnecessary here.

Proposed patch

• Resolve lefthookPackage.bin.lefthook under node_modules/lefthook.
• Execute that JavaScript entry with process.execPath and the arguments install --force.
• Keep the filtered Git environment, working directory, inherited stdio, error aggregation, hook-path migration, locking, and rollback behavior unchanged.
• Update the integration fixture to expose only the package bin entry and add a regression that runs the installer with NODE_OPTIONS=--throw-deprecation.

The local patch changes only:

• scripts/install-lefthook.mjs
• scripts/install-lefthook.spec.ts

Verification

The regression was first run against the unmodified launcher and failed with status 1 and DEP0190 at line 560. After the patch, these commands pass locally:

pnpm exec vitest run scripts/install-lefthook.spec.ts -t 'runs Lefthook without shell argument interpolation' --reporter=verbose
pnpm exec vitest run scripts/install-lefthook.spec.ts --reporter=dot
node --throw-deprecation scripts/install-lefthook.mjs
pnpm exec tsx scripts/run-oxlint.ts scripts/install-lefthook.mjs scripts/install-lefthook.spec.ts
git diff --check

The complete focused suite reports 33 passed and 6 skipped tests on Windows. The strict real-installer run exits 0, synchronizes the hooks, and emits no DEP0190 output.

[zoahdev]

Independent confirmation of the root cause and your fix direction — we hit the exact same DEP0190 pattern today in our own Windows CI scripts (spawning a .cmd shim via shell: true with separate args).

Two verified workarounds:

1. Your approach (cleanest when a JS bin exists): run the package's JS entry with process.execPath — no shell at all. For lefthook that's clearly the right fix.
2. When no JS entry exists: launch cmd.exe explicitly with an args array and no shell: true:

spawnSync('cmd.exe', ['/d', '/s', '/c', `${command} ${args.join(' ')}`], { windowsHide: true })

That avoids the deprecated shell:true + args interpolation while still resolving .cmd shims. One more data point for the report: bare spawnSync('pnpm.cmd', [...]) without shell: true does not work on Windows (Node treats .cmd shims as non-executable without a shell), which is exactly why the shim path triggers this trap.

Your regression idea (NODE_OPTIONS=--throw-deprecation) is the right way to keep this from regressing — thanks for the detailed report.