@vercel/og@1.0.2 throws WebAssembly.RuntimeError and aborts the process on import, from any working directory. 1.0.1 is unaffected.
Reproduction — three commands in an empty directory, no framework involved:
npm init -y
npm install @vercel/og@1.0.2
node -e 'require("@vercel/og")'Output (Node v22.22.2, Linux):
failed to asynchronously prepare wasm: Error: ENOENT: no such file or directory, open './hb.wasm'
Aborted(Error: ENOENT: no such file or directory, open './hb.wasm')
RuntimeError: Aborted(Error: ENOENT ... './hb.wasm'). Build with -sASSERTIONS for more info.
at abort (.../node_modules/@vercel/og/dist/index.node.js:3899:19)
Exit code 1. Swapping to @vercel/og@1.0.1 in the same directory exits 0.
Cause. 1.0.2 moves satori 0.29.0 → 0.33.3, which adds harfbuzzjs@0.10.0. dist/index.node.js inlines harfbuzz's emscripten loader, including:
function findWasmBinary() {
return locateFile("hb.wasm");
}locateFile is not overridden, so it resolves relative to the process working directory. The published tarball contains only dist/resvg.wasm and dist/yoga.wasm:
npm pack @vercel/og@1.0.2
tar tzf vercel-og-1.0.2.tgz | grep '\.wasm$'
# package/dist/resvg.wasm
# package/dist/yoga.wasm
So there is no hb.wasm for it to find. Because the failure happens at import rather than at render, it also does not degrade to the resvg-wasm fallback — the whole process goes down, taking any server that imports the package with it.
Expected: either hb.wasm ships alongside the other two wasm assets and locateFile resolves against the module directory rather than the CWD, or the bundle initializes harfbuzz lazily so import stays side-effect-free.
Environment: @vercel/og 1.0.2, satori 0.33.3, harfbuzzjs 0.10.0, Node v22.22.2, npm 10.9.7, Linux x64.
Related: #791 and #794 cover the bundler case for satori itself, where harfbuzzjs stays external and __dirname moves. This one is the published @vercel/og bundle: the loader is inlined with no locateFile override, so it fails from a plain require in a bare directory, with no bundler in the picture. The package.json bugs URL (github.com/vercel/og) is a 404, hence filing here like the other @vercel/og reports.
@vercel/og@1.0.2throwsWebAssembly.RuntimeErrorand aborts the process on import, from any working directory.1.0.1is unaffected.Reproduction — three commands in an empty directory, no framework involved:
npm init -y npm install @vercel/og@1.0.2 node -e 'require("@vercel/og")'Output (Node v22.22.2, Linux):
Exit code 1. Swapping to
@vercel/og@1.0.1in the same directory exits 0.Cause. 1.0.2 moves
satori0.29.0 → 0.33.3, which addsharfbuzzjs@0.10.0.dist/index.node.jsinlines harfbuzz's emscripten loader, including:locateFileis not overridden, so it resolves relative to the process working directory. The published tarball contains onlydist/resvg.wasmanddist/yoga.wasm:So there is no
hb.wasmfor it to find. Because the failure happens at import rather than at render, it also does not degrade to theresvg-wasmfallback — the whole process goes down, taking any server that imports the package with it.Expected: either
hb.wasmships alongside the other two wasm assets andlocateFileresolves against the module directory rather than the CWD, or the bundle initializes harfbuzz lazily so import stays side-effect-free.Environment:
@vercel/og1.0.2, satori 0.33.3, harfbuzzjs 0.10.0, Node v22.22.2, npm 10.9.7, Linux x64.Related: #791 and #794 cover the bundler case for satori itself, where
harfbuzzjsstays external and__dirnamemoves. This one is the published@vercel/ogbundle: the loader is inlined with nolocateFileoverride, so it fails from a plainrequirein a bare directory, with no bundler in the picture. The package.jsonbugsURL (github.com/vercel/og) is a 404, hence filing here like the other@vercel/ogreports.