Migrate the demo pages to MapLibre GL JS v6 (ESM)

[HuggeK]

The demo map on both golftiles.org and huggek.github.io/golfTiles has been blank for about three and a half weeks. Nothing we committed caused it, and nothing we commit would have fixed it.

Both pages loaded MapLibre from an unpinned URL:

<script src="https://unpkg.com/maplibre-gl/dist/maplibre-gl.js"></script>

unpkg resolves that to latest, and maplibre-gl 6.0.0 was published 2026-07-22. v6 is ESM-only — it ships dist/maplibre-gl.mjs and no longer publishes dist/maplibre-gl.js at all. So the script tag 404s, the maplibregl global is never defined, and the very first line of the demo script throws ReferenceError: maplibregl is not defined before a map is ever constructed. You get an empty <div id="map"> and nothing in the UI to explain it.

How this was confirmed

• https://unpkg.com/maplibre-gl/dist/maplibre-gl.js → 404. Probed every plausible bundle name — maplibre-gl.js, .umd.js, .min.js, .iife.js, .global.js all 404; only .mjs and the CSS return 200.
• v6's package.json has no main, no browser, no unpkg field — only module: dist/maplibre-gl.mjs and an ESM-only exports map.
• Dumped the live DOM of golftiles.org with a real browser: it still serves the unpinned tag.
• demo/local-viewer.html was pinned to @5, which is exactly why it kept working.

What this changes

All three demo pages move to v6 rather than pinning back to v5:

File	Serves	Was
index.html	golftiles.org	unpinned → broken
docs/index.html	GitHub Pages	unpinned → broken
demo/local-viewer.html	PR demo bundle	@5, working

The migration itself is small — v6 has no default export, so the namespace is imported inside the module script that was already there:

<script src="https://unpkg.com/pmtiles@3.2.0/dist/pmtiles.js"></script>
...
<script type='module'>
    import * as maplibregl from 'https://unpkg.com/maplibre-gl@6/dist/maplibre-gl.mjs';

pmtiles stays on 3.2.0. Its v3compat wrapper already detects the AbortController signature, so it works unchanged under v6 — verified, not assumed. Bumping it was unnecessary risk.

The CSS link is now pinned too. It happened to survive, but it was the same latent hazard.

Why pin the major version rather than an exact one

@6 matches the convention demo/local-viewer.html already used (@5), and it is what the MapLibre migration guide suggests. It still lets patch and minor releases through, but a future v7 with another breaking change cannot silently take the demo down the way v6 just did. If you would rather freeze completely, changing @6 to @6.4.0 in three places is the whole edit.

Verification

Driven in headless Chrome over the DevTools Protocol, loading each page as actually written — not a synthetic reproduction:

• maplibre-gl.mjs, maplibre-gl-shared.mjs and maplibre-gl-worker.mjs all load. The worker comes from the CDN cross-origin via MapLibre's blob module shim, so no self-hosting is needed.
• pmtiles range requests succeed and tiles decode.
• Zero console errors, zero failed requests on all three pages.
• Rendering matches v5 exactly: 247 rendered features across the same 16 layers on v5.24.0 and on v6.4.0.

demo/local-viewer.html was tested against a staged bundle (fixture tiles + style + viewer) over a Range-capable server, and renders Emmaboda Golfklubb fully — fairways, greens, bunkers, water, tee markers and labels.

Two pre-existing issues found while testing — not touched here

Both are unrelated to this migration and are left for separate PRs:

1. tees_borders has an invalid colour. v6 reports it precisely:
   layers[tees_borders].paint.line-color: Could not parse color from value 'yellow;red' Falling back to rgba(0,0,0,1).
   That looks like a raw OSM multi-value tag reaching the style. It renders black today.

2. No glyphs property in the style, although there are symbol layers using text-field with text-font: ["Open Sans Regular"]. It does not block loading — MapLibre falls back to rendering codepoints locally, which is why labels still appear — but there is no glyph server backing the configured font.