fix: react-maplibre - support maplibre-gl v6

[miketu926]

#2597

Fixes maplibre-gl v6 compatibility in the react-maplibre wrapper. v6 removed the public map.transform property (replaced by getCenter()/getZoom()/etc getters) and map.transformCameraUpdate field assignment (replaced by setTransformCameraUpdate()), and tightened .on()/setLayoutProperty()/setPaintProperty() typing to keyof MapEventType/AllLayoutProperties/AllPaintProperties. Runtime compat with v4/v5 is preserved via feature detection on setTransformCameraUpdate.

---

Note

Medium Risk
Touches core map camera sync, event wiring, and view-state propagation—behavior-sensitive paths—but changes are compatibility shims with v4/v5 fallbacks and added tests.

Overview
Updates react-maplibre for maplibre-gl v6 (dev dependency ^6.0.0) while keeping runtime behavior on v4/v5.

Camera / view state: v6 dropped public map.transform and transformCameraUpdate. The wrapper now builds camera snapshots via getTransformLike() (public getters) and registers camera updates with setTransformCameraUpdate() when present, otherwise the legacy property assignment.

Sizing: Controlled-size resize checks use getCanvas().clientWidth/Height instead of transform dimensions.

Types: Event listeners and layer setLayoutProperty / setPaintProperty calls use maplibre’s stricter MapEventType and AllLayoutProperties / AllPaintProperties keys; MapBoxZoomEvent is derived from MapEventType for the v6 type rename.

Tests cover getTransformLike (including pre-v5 elevation default); lockfile reflects the v6 dependency tree.

^{Reviewed by Cursor Bugbot for commit 49fdf12. Bugbot is set up for automated code reviews on this repo. Configure here.}

[miketu926]

• Xiaoji Chen
• Xintong Xia

[tordans]

Does the package have a setup to test each version separately?

[miketu926]

Does the package have a setup to test each version separately?

No.. CI only tests against whatever version is pinned in package.json (bumped to ^6.0.0 here). The v4/v5 fallback path is manually verified via type-checks, not an automated test.. that's been the case for this repo generally, not specific to this PR. Could open a follow-up for a version matrix if that's wanted.

[tordans]

CI only tests against whatever version is pinned in package.json (bumped to ^6.0.0 here). The v4/v5 fallback path is manually verified via type-checks, not an automated test.. that's been the case for this repo generally, not specific to this PR.

Thanks

Could open a follow-up for a version matrix if that's wanted.

Personally I think this would be a good addition given that we start working around version specifics. But maybe lets wait for a signal from the maintainers.

[chrisgervang]

Thanks for bringing this to my attention. I'm reviewing deck.gl's basemap integration now as well for v6 compatibility.

[chrisgervang]

Personally I think this would be a good addition given that we start working around version specifics. But maybe lets wait for a signal from the maintainers.

I could be open to it, though I'd like input from @Pessimistress since she's thought a lot about version compatibility. And as @miketu926 mentioned - the type system is catching the majority of version compatibility issues.

Overtime, we have had to drop support for older major versions when they diverge greatly - then we must document the last react-map-gl version with support for X basemap version.

[chrisgervang]

I traced the current CI failure and opened #2599 to move the repository CI/development runtime to Node.js 24.18.0. Once #2599 is merged, please rebase this PR onto master.

That removes the jsonlint Node engine blocker, but two PR-local failures remain afterward:

1. The MapLibre 6 dependency graph installs gl-matrix 3.4.4 alongside the existing 3.4.3, causing duplicate TypeScript declarations. Deduplicate gl-matrix at 3.4.4 and commit the resulting yarn.lock update. A root Yarn resolution to 3.4.4 is one validated approach.
2. Run Prettier on modules/react-maplibre/src/maplibre/maplibre.ts.

I validated that Node 24 plus the gl-matrix 3.4.4 resolution builds successfully; yarn lint then reports only that formatting issue from this PR.

[Pessimistress]

I suspect we may get more divergence as v6 development continues, and will eventually need a dedicated endpoint. But for now the changes seem manageable.

[miketu926]

@Pessimistress updated MCs against latest

[chrisgervang]

Is this fine with you @miketu926? I'm trying to be a little less brittle here