chore(deps): pin libheif-js 1.23.2 in the lockfile so CI tests what consumers install

[AminDhouib]

Pins libheif-js at 1.23.2 in the lockfile so the HEIC integration suite runs against the version consumers actually install. Four lines, one package; packages/core/package.json is untouched.

Why

Consumer	Range	Resolves to
This workspace (lockfile)	^1.19.8 (core optionalDependency)	1.19.8
Any lockfile-less install — the package smoke consumer, and every real user	^1.19.8	1.23.2 (npm view libheif-js version; the published 1.x list ends …1.18.2, 1.19.8, 1.23.2)

So packages/core/tests/integration/heic-decode.integration.test.ts — the only place a real HEIC is decoded through heic-decode.ts — proved a decoder nobody installs. smoke:packages does install 1.23.2, but assertConsumerBundleShape only measures bundle shape and asset size; it never executes a decode. Nothing in CI exercised the version users get, which is how #378 could re-base the opt-in chunk budget from ~1425 KiB to 1939.4 KiB for a decoder that had never been run.

Verified before pinning

1.23.2 decodes the repo's real 64×64 HEIC fixture through our own code path, unchanged:

• Module shape identical — default is the factory; HeifDecoder / decode / get_width / get_height / display / free / heif_context_free all behave as heic-decode.ts expects.
• 406 source bytes → 64x64 decoded → 785-byte JPEG, SOI 0xff 0xd8, EOI 0xff 0xd9, re-decoded back to 64x64 by @napi-rs/canvas. Byte-identical to 1.19.8 on every one of those numbers.
• The integration suite passed against 1.23.2 before this change too (run through a temporary vitest alias into an isolated install). That alias was proven live by pointing it at a nonexistent path and watching all 5 tests skip, so the green was not a silent fallback to 1.19.8.

Why the lockfile was edited by hand

pnpm's own commands could not produce a narrow diff:

Command	Result
pnpm update libheif-js --filter @useupup/core	2828 changed lines and rewrote core's manifest range to ^1.23.2
pnpm add libheif-js@^1.19.8 --filter @useupup/core --save-optional	manifest preserved, but still 1194 changed lines across unrelated peer graphs — including a vitest 4.1.11 → 4.1.2 downgrade, plus @typescript-eslint/*, @vue/language-core, ts-api-utils

Control experiment: a plain pnpm install with no dependency change produced no lockfile diff, so that churn comes from the re-resolution itself, not from pre-existing lockfile drift. Both attempts were reverted and the tree restored with --frozen-lockfile before the hand edit.

The edit is three hunks — the importer's resolved version, the packages entry (version + integrity, taken from npm view libheif-js@1.23.2 dist.integrity), and the snapshots entry. 1.23.2 has no dependencies and the same engines as 1.19.8, so nothing else in the graph moves. pnpm install --frozen-lockfile accepts it — that command refuses to rewrite a lockfile, so its success is the proof that the file is self-consistent, and it left the diff at exactly those four lines.

Confirming the bump did something

Three independent checks after installing:

• packages/core/node_modules/libheif-js/package.json → 1.23.2
• pnpm --filter @useupup/core list libheif-js → libheif-js 1.23.2
• Resolving the exact specifier the source imports, from the source file's own directory: require.resolve('libheif-js/libheif-wasm/libheif-bundle.mjs') → node_modules/.pnpm/libheif-js@1.23.2/…

No changeset

Deliberate, not an oversight: libheif-js is an optionalDependency resolved at the consumer's own install, and core's ^1.19.8 range is unchanged — consumers already received 1.23.2 and still will. This moves what we test, not what anyone receives, so there is no published-artifact change to describe.

Gates (all via rtk proxy, raw exit codes)

Gate	Result
pnpm install --frozen-lockfile	exit 0 (lockfile accepted unmodified)
pnpm --filter @useupup/core exec vitest run tests/integration/heic-decode.integration.test.ts	5 passed, exit 0
pnpm --filter @useupup/core test	143 files / 1741 passed, exit 0
pnpm run typecheck	31/31 tasks, exit 0
pre-commit (core + react + server suites)	green
pre-push (typecheck + lint + knip)	green

pnpm-lock.yaml is listed in .prettierignore and prettier --check reports it clean either way.

Related, not in scope

.size-limit.json has no HEIC/libheif entry — core's 410 KB budget covers the mandatory path only, which is why a ~1.9 MB opt-in chunk cannot red it. That is by design (the opt-in path is guarded by consumerOptionalChunkBudget in the smoke consumer), so this PR leaves it alone.

[codesandbox]

Review or Edit in CodeSandbox

Open the branch in Web Editor • VS Code • Insiders

Open Preview