chore(deps): move from image-size to probe-image-size

[amitsharma-turbodocx]

Ports #207 by @elefevre (Eric Lefevre-Ardant) onto develop. The original PR targeted main; this is the same change rebased onto our integration branch, with credit preserved (Co-authored-by: on the commit, plus elefevre added to contributors in package.json).

Closes #207.

Why

image-size is archived and is flagged by scanners (Snyk, high severity) for infinite-loop DoS on malformed inputs:

• ICNS — SNYK-JS-IMAGESIZE-17295814
• HEIF / JP2 / JXL — same advisory family

Practical risk for us is low (none of those are formats you'd embed in a DOCX), but the package is unmaintained, so the fix will never land upstream.

probe-image-size is maintained and covers every format we actually care about: png, jpeg, gif, bmp, webp, tiff, psd, ico, avif, svg.

What changed

File	Change
package.json	image-size@^2.0.2 → probe-image-size@^7.2.3; elefevre added to contributors
package-lock.json	regenerated (npm 11 / lockfile v3, matching CI's Node 24)
src/helpers/xml-builder.js	import swap
src/utils/image.js	import swap

No call-site logic changed.

One deviation from #207

#207 used import { sync as sizeOf } from 'probe-image-size'. This PR uses:

import sizeOf from 'probe-image-size/sync';

The package root entry requires needle, which drags http/https/zlib/iconv-lite/sax in with it. Our rollup.config.js bundles everything except sharp into dist/html-to-docx.browser.js and dist/html-to-docx.browser.esm.js, so the root import would have shipped a Node HTTP client into the browser builds. We only ever probe Buffers, so the sync entry is all we need.

Verified against a fresh build — no needle, no iconv-lite, no sax in the browser bundle.

Compatibility

sizeOf(buffer) still returns { width, height }, and all three call sites already sit inside try/catch with a falsy-dimension guard:

• src/helpers/xml-builder.js:1159 (remote image in buildRun)
• src/helpers/xml-builder.js:1727 (base64 / data-URL helper)
• src/utils/image.js:516 (buildImage)

The one behavioural difference is that probe.sync returns null on unrecognised input where image-size threw. Both paths are already handled by the existing guards, so nothing needed to change.

Measured against our fixtures:

Input	Result
banner.png	1200 × 300 px ✅
tests/fixtures/test-1x1.{png,gif,jpg}	1 × 1 px ✅
SVG with width/height in px	120 × 60 px ✅
SVG with viewBox only	300 × 150 px ✅
SVG with width="100%"	falls back to viewBox → 300 × 150 px ✅
garbage bytes / empty buffer	null → caught by existing guard ✅

Verification

npx jest tests/image-processing.test.js    → 75 passed
npx jest tests/svg-handling.test.js        → 53 passed
npx jest tests/inline-image-caching.test.js → 12 passed
npx jest tests/inline-svg-element.test.js  → 10 passed
npm run build                              → all 4 bundles emitted
npm audit --omit=dev                       → 0 vulnerabilities

End-to-end smoke test through dist/html-to-docx.esm.js with a 1200×300 PNG produced <wp:extent cx="5486400" cy="1371600"/> — the correct 4:1 aspect ratio.

Trade-offs worth a look before merge

1. probe-image-size hard-depends on needle@^2, iconv-lite@0.4.24, sax, safer-buffer. They're excluded from our bundles, but they still get installed for anyone running npm i @turbodocx/html-to-docx, so they'll show up in consumers' Dependabot/Snyk scans. npm audit --omit=dev is clean today, but needle is effectively unmaintained — we're trading one stale dep for another, just one that isn't currently flagged.

2. Narrower format support. We lose cur, dds, icns, j2c/jp2, jxl, ktx, pnm, tga — none of which are valid DOCX image parts. Everything Word can actually embed is covered, and heif/heic/avif carry over (probe parses them via its MIAF parser).

3. ⚠️ SVG units — a real behavioural change, not a theoretical one. probe.sync reports wUnits/hUnits and returns the raw number; image-size converted units to px. The call sites ignore units and treat the number as px, so a unit-bearing SVG comes out smaller:

   <svg width="72pt" height="36pt">	result
   image-size@2	96 × 48 px
   probe-image-size/sync	72 × 36 (wUnits: "pt")

   I originally wrote this off as unreachable because buildImage short-circuits on response.isSVG — but that guard only exists in src/utils/image.js. The two sizeOf call sites in src/helpers/xml-builder.js (1159 and 1727) have no isSVG check, so an SVG reaches sizeOf whenever it stays an SVG in the media part — i.e. svgHandling: "native", or "convert" falling back because sharp isn't installed.

   Reproduced end-to-end on this branch: a 72pt × 36pt SVG inside <span><img></span> with svgHandling: "native" emits <wp:extent cx="685800" cy="342900"/> (= 72 × 36 px). On image-size the same input measures 96 × 48, i.e. cx="914400" — a 25% shrink.

   Unit-less and px SVGs are unaffected, and %-width SVGs actually improve (probe falls back to the viewBox instead of returning the percentage). TurboDocx's own pipeline ships sharp, so SVGs are rasterised to PNG before sizeOf and production is not exposed — but library consumers without sharp are.

   Suggested fix before merge: normalise units at the call sites (multiply through SVG_UNIT_TO_PIXEL_CONVERSIONS when wUnits !== "px"), or add the same isSVG short-circuit the buildImage path already has. Happy to push either onto this branch.

---

Cross-repo

Backend PR: nicolasiscoding/RapidDocxBackend#1722 — adds probe-image-size to the backend's own dependencies (the compiled submodule resolves it from there, not from this repo's node_modules), migrates pptx-injection off image-size with a null guard, and bumps the submodule pointer.

Change record: nicolasiscoding/RapidDocxBackend#1718

Both must land together — the backend pins the sizing library for the compiled submodule, so the pointer bump and the dependency swap cannot be split without a window where the two disagree.

---

Credit to @elefevre for finding this and doing the original work.

[github-actions]

TurboDocx DOCX Diff Report

Automated HTML to DOCX regression testing | Powered by TurboDocx

Summary

• ✅ Identical files: 71
• 🔄 Changed files: 0
• ➕ New files: 0
• ➖ Deleted files: 0

---

🚀 Powered by TurboDocx | html-to-docx

Automated DOCX regression testing • Catch document generation bugs before they ship • 100% open source

Generated by TurboDocx DOCX Diff workflow • Learn more