Worker bundle grows 3.3 → 7.4 MB on main: the Utils barrel pulls web-ifc into the worker

[rihokirss]

Describe the bug 📝

packages/fragments/dist/Worker/worker.mjs built from c4d48d7 (the 3.4.7 bump) is 3 276 108 bytes (gzip 446 KB). Built from main @ dceedc8 it is 7 429 033 bytes (gzip 767 KB). The main-thread bundle is unaffected (1.36 → 1.37 MB).

The difference is web-ifc. dceedc8 ("fix(parser): streaming STEP tokenizer with web-ifc tape parity") added Utils/ifc-parsing-utils.ts, which does

import * as webIfc from "web-ifc";
…
const { STRING, LABEL, ENUM, REAL, REF, INTEGER } = webIfc;
…
const typecode = (webIfc as Record<string, unknown>)[name.toUpperCase()];

and Utils/index.ts now re-exports it (export * from "./ifc-parsing-utils"; export * from "./ifc-stream";). The worker entry reaches that barrel — virtual-fragments-model.ts and edit-request-index.ts import EditRequest/EditUtils from ../../../Utils — and since the worker build cannot externalise anything, the whole web-ifc module (with its wasm loader glue) lands in the worker, where nothing calls it. Every app ships this file to every visitor; the old worker had zero references to IfcAPI/web-ifc, the new one has 12.

What I expect: the worker bundle contains what the worker runs.

What actually happens: +4.1 MB (+320 KB gzipped) of web-ifc in the worker.

Suggested fix: define the six token codes locally (they are small integer constants) or import them from a constants-only module, and keep ifc-parsing-utils/ifc-stream out of the barrel the worker imports (export them from the package index instead). Worth landing before 3.5.0 (#189), since the release would otherwise double the worker download for everyone.

Reproduction ▶️

yarn install && yarn build-core on c4d48d7 and on main, then compare packages/fragments/dist/Worker/worker.mjs (ls -l, grep -c IfcAPI).

Steps to reproduce 🔢

1. Build main (dceedc8).
2. ls -l packages/fragments/dist/Worker/worker.mjs → 7.4 MB; grep -c "IfcAPI" …/worker.mjs → 12.
3. Same on c4d48d7 → 3.3 MB, 0 matches.

System Info 💻

  Node 24, yarn 3.2.1 (vendored), vite 5 worker build from vite.config-worker.ts
  web-ifc 0.0.77

Used Package Manager 📦

yarn

Validations ✅

• Read the docs.
• Checked there isn't already an issue that reports the same bug.
• This is a repository issue, not a framework issue.
• This is a concrete bug.
• The reproduction is minimal.

[ShaMan123]

Good catch!
I encountered this issue in my app and forgot about the PR.

[ShaMan123]

web-ifc should export its consts as a standalone entry point.

[ShaMan123]

In fact I would suggest that web-ifc exposes everything needed for IfcParserStream to operate without pulling the entire bundle in @agviegas

[agviegas]

Fixed on main: the Utils barrel re-exported the STEP parsing layer (and the splitter that imports it), and the worker imports the barrel, so web-ifc's API glue and schema tables were retained. Those three modules now export from the package root instead; the public API is unchanged. The worker is back to 3.5 MB with zero web-ifc traces. Thanks for the sharp report, the import chain you traced was exactly right.