852310d05e
Some checks are pending
build-gate / build (push) Waiting to run
resolveAssetsBase computed `<treeRoot>/../assets` -- one path segment too high.
This reached the live site. MEASURED by publishing to the catalog and reverting:
leaf .../doxa-maps/my-upg-100-list/upg-100-list/index.html + '../../assets'
-> /plugin-assets/doxa-maps/assets 200
code root '/plugin-assets/doxa-maps' + '/../assets'
-> /plugin-assets/assets 404
The UPG-100 map went from "195 polys · 27/27 zones · 2107 pins" to
"⚠ boundary fetch 404 world-adm0.geojson" -- a basemap with none of our data on
it. Reverted within minutes; live is healthy.
★ THE COMMENT JUSTIFIED THE OFF-BY-ONE IN PROSE, which is how it survived. It
said the pool is "a SIBLING of the tree -- <root>/../assets -- which is why the
leaf page's generated value is '../../assets' (two up from
<tree>/<bundle>/<profile>/)". Two up from <tree>/<bundle>/<profile>/ is <tree>,
not the tree's parent. The arithmetic was wrong and the sentence made it read
deliberate. generate-tree stages assets INSIDE the tree on purpose -- "staged N
runtime asset(s) -> doxa-maps/assets", so a dropped folder is self-contained.
⚠ WHY FIFTEEN TICKS OF GREEN GATES MISSED IT, three independent reasons:
1. INVISIBLE LOCALLY. The dev web-root has BOTH public/assets (a sibling) and
public/doxa-maps/assets (inside), each holding the boundaries -- so the
wrong path RESOLVES on 127.0.0.1. The catalog publishes app/doxa-maps only;
no sibling exists there. No local run can tell the answers apart.
2. THE BYTE GATES PASSED. check:published and check:catalog-currency both went
GREEN on the broken publish -- 22 of 22 byte-identical, 0 stale. They prove
the bytes match, not that the page works.
3. NO GATE REFERENCED THE FUNCTION, while 10+ profiles across 6 bundles call
it.
So the fix ships with check:embed-base, which is PURE ARITHMETIC -- no browser,
no network, no served tree, so it cannot SKIP itself into irrelevance. It
computes what a leaf's own '../../assets' means and asserts the resolver agrees:
the oracle is what the generated HTML already says, not an opinion about where
assets belong. It also pins the explicit ladder rungs, so a narrow fix cannot
swallow a host-supplied assetsBase.
MUTATION-TESTED: restoring the original '/../assets' fails all four tree roots
(live catalog, dev, doxa.life drop-in, deep subpath) in milliseconds.
|
||
|---|---|---|
| .. | ||
| .gitkeep | ||
| apiBaseUrl.js | ||
| ClusterHelpers.js | ||
| countries-meta.js | ||
| DataSourceManager.js | ||
| embedBase.js | ||
| geoUtils.js | ||
| MSTClusteringUtil.js | ||
| NetworkClusteringUtil.js | ||
| README.md | ||
| viewportScrim.js | ||
library/utils/ — pure JS helpers
No Vue, no Pinia, no Mapbox. Anything reactive is a composable; anything stateful is a store.
| File | Purpose |
|---|---|
apiBaseUrl.js |
Resolves the API base URL at runtime (window.MAP_APP_API_URL / VITE_API_BASE_URL) |
embedBase.js |
Share/embed URL ladder — the built bundle derives its tree root from its own script url (profileConfig.shareUrl / embedBaseUrl / window.MAP_EMBED_BASE_URL override) so tree-relative <bundle>/<profile>/index.html links work on any host |
geoUtils.js |
Centroid, bounds, validation, GeoJSON helpers |
ClusterHelpers.js |
Shared helpers for the two clustering utilities below |
MSTClusteringUtil.js |
Minimum-spanning-tree clustering for affinity blocks |
NetworkClusteringUtil.js |
Network-line clustering — connect nearby pins with edges |
- No
import { ref } from 'vue'and noimport mapboxglin this folder — operate on plain[lng, lat]arrays. - Named exports (for tree-shaking), JSDoc on every export.
- Writing reactive logic or needing Mapbox APIs? That's a composable — move it to
../composables/.