pnpm i --fix-lockfile removes 'hasBin' 'deprecated' fields and not regenerated them

pnpm version:

8.5.1

Code to reproduce the issue:

run pnpm i --fix-lockfile

Expected behavior:

repo that already has up-to-date lockfile runs pnpm i --fix-lockfile and lockfile do not change anything

Actual behavior:

remove 'hasBin' 'deprecated' field,
these fields will be regenerated one day, if related-dependencies are changed, a large number of lockfile rows have been modified,so, it's better not to change this.

Additional information:

By the way, the lockfile format can have a document that may make the user clearer about what changes in the lockfile.

Maybe I can change it here, but I don't know what the hasBin field usage is , and why it won't been regenerated and whether there are other fields like 'hasBin' and 'deprecated'

pnpm/pkg-manager/core/src/install/index.ts

Lines 959 to 973 in a53ef4d

    
           // Ignore some fields when fixing lockfile, so these fields can be regenerated 
        
           // and make sure it's up to date 
        
           if ( 
        
             opts.fixLockfile && 
        
             (ctx.wantedLockfile.packages != null) && 
        
             !isEmpty(ctx.wantedLockfile.packages) 
        
           ) { 
        
             ctx.wantedLockfile.packages = mapValues(({ dependencies, optionalDependencies, resolution }) => ({ 
        
               // These fields are needed to avoid losing information of the locked dependencies if these fields are not broken 
        
               // If these fields are broken, they will also be regenerated 
        
               dependencies, 
        
               optionalDependencies, 
        
               resolution, 
        
             }), ctx.wantedLockfile.packages) 
        
           }

This still seems to be happening. On 9.1.1 I was seeing node-pre-gyp getting it's hasBin: true getting removed which resulted in CI failing for some downstream dependency because the postinstall script using it failed.

For me it was jsdom -> node-canvas's postinstall to grab the canvas binary that was failing. node-canvas relies on node-pre-gyp's binary existing. That binary was suddenly no longer available because I had used --fix-lockfile to resolve a pnpm-lockfile merge. The only fix seemed to be manually adding back the hasBin: true for the dependency of a dependency of a dependency.

@schickling

Minimal standalone reproduction for the current pnpm 11 regression:

https://github.com/schickling-repros/2026-07-pnpm-fix-lockfile-hasbin

./repro.sh

It uses only cowsay@1.6.0 from the public npm registry. pnpm 11.3.0 creates
one hasBin: true entry; pnpm 11.8.0 then runs
install --fix-lockfile --lockfile-only against the unchanged graph and
rewrites that count to zero. npm view cowsay@1.6.0 bin --json still reports
both cowsay and cowthink, so this is lockfile metadata loss rather than bad
registry metadata or repository policy.

Version matrix from the same repro:

pnpm	result
11.3.0 through 11.5.1	preserves `hasBin`
11.5.2 through 11.14.0	removes `hasBin`
12.0.0-alpha.14	preserves `hasBin`

This is behaviorally consistent with the v11 --fix-lockfile resolution path
failing to carry or regenerate executable metadata for unchanged package
records. Newly resolved records can retain the field, which makes a large
lockfile diff look selective. Lockfile-driven linking can subsequently omit
command shims, as described in the earlier node-pre-gyp report above.

Current v11 workaround:

corepack pnpm@11.3.0 --pm-on-fail=ignore install --fix-lockfile --lockfile-only
corepack pnpm@11.8.0 install --frozen-lockfile

The first command restores the missing metadata; pnpm 11.8.0 can consume the
repaired lockfile without rewriting it. Avoid --fix-lockfile on affected v11
versions.

Tested with Node.js 24.15.0 on Linux x86_64.

Posted on behalf of @schickling

field	value
`agent_name`	☁️ co3-billow
`agent_session_id`	7f3b9666-034f-4e9e-890b-491957f7f75b
`agent_tool`	Codex CLI
`agent_tool_version`	0.144.1
`agent_runtime`	Codex CLI 0.144.1
`agent_model`	unknown
`runtime_profile`	/nix/store/1n76sy6i9y3ki3k4w04jksqvygw67sj0-coding-agent-runtime-profile/share/coding-agents/profile.json
`skills_manifest`	/nix/store/jn6r0r7r59x3a525jch4pwzwykszqp60-agent-skills-corpus/share/agent-skills/manifest.json
`worktree`	2026-07-pnpm-fix-lockfile-hasbin/main
`machine`	dev3
`tooling_profile`	dotfiles@4eac376

chore(deps): pin pnpm 12.3.4 and retire the separate lock mutator

This no longer reproduces on current pnpm, so closing.

Verified on pnpm 12.5.1: pnpm install --fix-lockfile leaves an up-to-date lockfile untouched, hasBin and deprecated fields included.

If you still hit this on the latest pnpm, please comment with a reproduction and we will reopen.

Written by an agent (Claude Code, claude-opus-5).

Out of curiosity: Will this be backported to PNPM 11?

fix: preserve hasBin and deprecated fields in lockfile during --fix-l…

fix: keep deprecated and hasBin in the lockfile on install --fix-lock…

fix(deps): update dependencias no-major (#34)

chore(deps): update pnpm to v12.10.1

Navigation Menu

Repository navigation

pnpm i --fix-lockfile removes 'hasBin' 'deprecated' fields and not regenerated them #6600

pnpm version:

Code to reproduce the issue:

Expected behavior:

Actual behavior:

Additional information:

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	// Ignore some fields when fixing lockfile, so these fields can be regenerated
	// and make sure it's up to date
	if (
	opts.fixLockfile &&
	(ctx.wantedLockfile.packages != null) &&
	!isEmpty(ctx.wantedLockfile.packages)
	) {
	ctx.wantedLockfile.packages = mapValues(({ dependencies, optionalDependencies, resolution }) => ({
	// These fields are needed to avoid losing information of the locked dependencies if these fields are not broken
	// If these fields are broken, they will also be regenerated
	dependencies,
	optionalDependencies,
	resolution,
	}), ctx.wantedLockfile.packages)
	}

pnpm i --fix-lockfile removes 'hasBin' 'deprecated' fields and not regenerated them #6600

Description

pnpm version:

Code to reproduce the issue:

Expected behavior:

Actual behavior:

Additional information:

Activity

SoonIter commented on May 27, 2023

msluther commented on Jul 12, 2024

schickling-assistant commented on Jul 18, 2026

zkochan commented on Sep 19, 2026

clemens commented on Sep 23, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions