What happens
Every visit to a page carrying an ObjectMap widget fires a 404 for a local
console asset:
404 /_console/assets/maplibre-gl-worker.mjs
Reproduced on showcase_task_map
(/_console/apps/com.example.showcase/page/showcase_task_map) against a
vendored console built from f5bc4c78be76.
Why
maplibre-gl's ESM distribution resolves its worker as a sibling of its own
script URL rather than importing it, so the bundler never sees an edge to
follow. From the built chunk assets/maplibre-gl-DXuUDjK2.js:
let t = e.endsWith(`-dev.mjs`) ? `maplibre-gl-worker-dev.mjs` : `maplibre-gl-worker.mjs`;
return new URL(`./${t}`, e).hrefVite bundles maplibre-gl into a hashed chunk under assets/ and emits nothing
beside it, so that computed URL resolves to /_console/assets/maplibre-gl-worker.mjs
— which does not exist:
$ ls packages/console/dist/assets | grep -i maplibre
maplibre-gl-DXuUDjK2.js
maplibre-gl-DXuUDjK2.js.br
maplibre-gl-DXuUDjK2.js.gz
$ curl -o /dev/null -w '%{http_code}' http://localhost:3000/_console/assets/maplibre-gl-worker.mjs
404
apps/console/vite.config.ts lists maplibre-gl in optimizeDeps.include
(~L219) but nothing arranges for the worker file to ship.
Scope / severity
This is not the same thing as the external-tiles failure. On the same page
the demo style is also unreachable here:
Map failed to load (AJAXError: Failed to fetch (0): https://demotiles.maplibre.org/style.json).
Markers below are still listed in the search box; configure a custom map style for production use.
That one is this sandbox's egress policy, and the widget degrades gracefully
with a clear message and a listed-markers fallback — working as designed.
The worker 404 is different: it is a first-party asset missing from our own
build, so it 404s in every deployment, air-gapped or not.
What I could not determine here: whether the missing worker alone breaks
tile rendering, because external tiles are blocked in this environment, so I
could never get a map to paint. It should be confirmed against a reachable
style URL (or a self-hosted one) before deciding how urgent this is — maplibre
may fall back to main-thread parsing, in which case the user-visible cost is a
404 plus a slower map rather than a blank one.
That same limitation is why I am filing this rather than fixing it: I cannot
verify a fix end-to-end from here.
Suggested direction
Emit the worker next to its chunk, e.g. a small vite-plugin / generateBundle
hook (or viteStaticCopy) that copies maplibre-gl/dist/maplibre-gl-worker.mjs
into assets/, and a build assertion so a future maplibre bump that renames it
fails loudly instead of 404ing at runtime — the same "no silent drift" posture
scripts/build-console.sh already takes with its CONSOLE_BUNDLE_CANARY.
Repro
os dev --ui --seed-admin in examples/app-showcase- Sign in, open
/_console/apps/com.example.showcase/page/showcase_task_map
- Network panel →
maplibre-gl-worker.mjs 404
Found while browser-sweeping showcase + Studio for objectstack#4879.
What happens
Every visit to a page carrying an
ObjectMapwidget fires a 404 for a localconsole asset:
Reproduced on
showcase_task_map(
/_console/apps/com.example.showcase/page/showcase_task_map) against avendored console built from
f5bc4c78be76.Why
maplibre-gl's ESM distribution resolves its worker as a sibling of its ownscript URL rather than importing it, so the bundler never sees an edge to
follow. From the built chunk
assets/maplibre-gl-DXuUDjK2.js:Vite bundles
maplibre-glinto a hashed chunk underassets/and emits nothingbeside it, so that computed URL resolves to
/_console/assets/maplibre-gl-worker.mjs— which does not exist:
apps/console/vite.config.tslistsmaplibre-glinoptimizeDeps.include(~L219) but nothing arranges for the worker file to ship.
Scope / severity
This is not the same thing as the external-tiles failure. On the same page
the demo style is also unreachable here:
That one is this sandbox's egress policy, and the widget degrades gracefully
with a clear message and a listed-markers fallback — working as designed.
The worker 404 is different: it is a first-party asset missing from our own
build, so it 404s in every deployment, air-gapped or not.
What I could not determine here: whether the missing worker alone breaks
tile rendering, because external tiles are blocked in this environment, so I
could never get a map to paint. It should be confirmed against a reachable
style URL (or a self-hosted one) before deciding how urgent this is — maplibre
may fall back to main-thread parsing, in which case the user-visible cost is a
404 plus a slower map rather than a blank one.
That same limitation is why I am filing this rather than fixing it: I cannot
verify a fix end-to-end from here.
Suggested direction
Emit the worker next to its chunk, e.g. a small
vite-plugin/generateBundlehook (or
viteStaticCopy) that copiesmaplibre-gl/dist/maplibre-gl-worker.mjsinto
assets/, and a build assertion so a future maplibre bump that renames itfails loudly instead of 404ing at runtime — the same "no silent drift" posture
scripts/build-console.shalready takes with itsCONSOLE_BUNDLE_CANARY.Repro
os dev --ui --seed-admininexamples/app-showcase/_console/apps/com.example.showcase/page/showcase_task_mapmaplibre-gl-worker.mjs404Found while browser-sweeping showcase + Studio for objectstack#4879.