My scripted migration inserted the import behind a guard that silently did not fire:
`if 'defineMapElement' not in s.split('function')[0]` became false as soon as the
inserted CALL appeared before the first `function` keyword — so the files that most
needed the import were exactly the ones that did not get it. 11 of 16.
Every one of those elements would have thrown "defineMapElement is not defined" on
load. A bundler does not error on a free identifier; only loading does. studio caught it
in L64 via landing-preconditions, which imports each profile, and fixed it there
(37f75601) plus added an arm to check:element-bootstrap.
This repairs the same 11 on this branch so it is not a landmine if it lands after L64,
and it is byte-equivalent to studio's fix in effect. Verified by PARSING each entry and
resolving the identifier against its import bindings — 16 of 16 bound — rather than by
re-running the kind of regex that wrote the bug.
17 lines
939 B
JavaScript
17 lines
939 B
JavaScript
import { defineMapElement } from '@map/elements/defineMapElement.js'
|
|
/**
|
|
* pplr-data-maps / index.js — bundle entry (emits pplr-data-maps.js), defines <pplr-data-maps>.
|
|
*
|
|
* The standard ProfileLoader shape (see doxa-simple-map/index.js): the glob captures this
|
|
* folder's one profile, pplr-data-maps.vue; its ten views live in src/views/. The Mapbox RTL
|
|
* text plugin is registered once here: many PG names are Arabic, Urdu or Hebrew.
|
|
*/
|
|
|
|
const profileModules = import.meta.glob('./*.vue')
|
|
|
|
// RTL text plugin (Arabic/Hebrew/Persian shaping): installed by useMapInstance through
|
|
// library/maps/rtl-text.js, on BOTH engines, before every map is constructed. Do not re-add a
|
|
// hand-rolled mapboxgl-only block here -- it was a strict subset of that call.
|
|
|
|
const El = defineMapElement({ profileModules })
|
|
if (typeof customElements !== 'undefined' && !customElements.get('pplr-data-maps')) customElements.define('pplr-data-maps', El)
|