package.json pins "engines": {"node": ">=20"}, and the README/docs don't make any claim either way about browser or edge-runtime (Cloudflare Workers, Deno, etc.) support. Went looking for actual Node-only APIs to see whether the engines pin reflects a real constraint or just a CI/tooling default: src/zip.ts only imports from fflate (pure JS), and src/package-io/read.ts/write.ts only import internal modules plus bytesToBase64/base64ToBytes -- no node:fs, node:buffer, or other Node builtins in that whole decode/encode hot path. That's genuinely encouraging for a Workers use case, but I didn't audit document-schema.js/fast-xml-parser/zod transitively, and an unenforced-but-stated engines field is exactly the kind of thing a bundler or npm install --engine-strict context can reject on regardless of whether the code itself would actually run.
Ran into this specifically wanting to call readXlsxContent/decodePackage from inside a Cloudflare Worker (no Node fs, no Buffer global by default) as a fallback for xlsx extraction. Would help to either: state a real compatibility stance in the README (isomorphic and tested against workerd/browser, or Node-only and why), or add a smoke test that actually exercises the package under a non-Node runtime (e.g. wrangler dev or miniflare) so "isomorphic" is verified rather than asserted.
package.json pins
"engines": {"node": ">=20"}, and the README/docs don't make any claim either way about browser or edge-runtime (Cloudflare Workers, Deno, etc.) support. Went looking for actual Node-only APIs to see whether the engines pin reflects a real constraint or just a CI/tooling default:src/zip.tsonly imports fromfflate(pure JS), andsrc/package-io/read.ts/write.tsonly import internal modules plusbytesToBase64/base64ToBytes-- nonode:fs,node:buffer, or other Node builtins in that whole decode/encode hot path. That's genuinely encouraging for a Workers use case, but I didn't auditdocument-schema.js/fast-xml-parser/zodtransitively, and an unenforced-but-statedenginesfield is exactly the kind of thing a bundler ornpm install --engine-strictcontext can reject on regardless of whether the code itself would actually run.Ran into this specifically wanting to call
readXlsxContent/decodePackagefrom inside a Cloudflare Worker (no Node fs, no Buffer global by default) as a fallback for xlsx extraction. Would help to either: state a real compatibility stance in the README (isomorphic and tested against workerd/browser, or Node-only and why), or add a smoke test that actually exercises the package under a non-Node runtime (e.g.wrangler devorminiflare) so "isomorphic" is verified rather than asserted.