Update maplibre-gl to 6.x - #61
Conversation
maplibre-gl ships ES modules only since 6.0, with no UMD build left to concatenate, so the GL bundle is rolled up by esbuild instead. It still exposes the `maplibregl` global, and Leaflet is aliased to the instance the page already loaded rather than embedded a second time. The tile parsing worker can no longer be inlined; it is built beside the bundle as maps-gl.worker.min.js, and the bundle points maplibre at it from its own script URL, so no template has to know where plugin resources are served from. Keep the bundler sources out of released archives
gagnieray
left a comment
gagnieray
left a comment
There was a problem hiding this comment.
So esbuild is a more performant alternative to webpack 👍
The goal is therefore to use ESM modules without modifying the existing standard JS code.
At first glance, everything seems logical and correct to me.
In any case, it does the job well and works properly 😃
(Additional remark regarding JS management in Galette after digging into this PR: it would be really great to find a way to remove all the JS code from the twig templates and let the controllers load only the JS files they need, rather than concatenating everything into large JS bundles. Easier said than done, of course 😅)
That was my point too :)
Yes... We probably should talk about that, and what would be possible - to be honest I almost have no idea what would be the better approach. |
2 participants
Following #55
maplibre-gl ships ES modules only since 6.0, with no UMD build left to concatenate, so the GL bundle is rolled up by esbuild instead. It still exposes the
maplibreglglobal, and Leaflet is aliased to the instance the page already loaded rather than embedded a second time.The tile parsing worker can no longer be inlined; it is built beside the bundle as maps-gl.worker.min.js, and the bundle points maplibre at it from its own script URL, so no template has to know where plugin resources are served from.
Also, keep the bundler sources out of released archives