React SDK 0.2.0 — 21 packages, a rename, and what does not load outside a bundler

The MapConductor React SDK is now at 0.2.0 — 21 packages on npm, all Apache-2.0. @mapconductor/react-for-openlayers is at 0.2.1, for a fix described at the end.

What changed

• Every package moved to a single version. Internal @mapconductor/* ranges moved with them, so a mixed install cannot happen by accident.
• @mapconductor/react-geojson-layer is now @mapconductor/react-geojson. Only the package name changed; GeoJSONLayer, GeoJSONLayerState, GeoJSONParser and the rest of the API are untouched. The old package stays on npm at 0.1.3 and receives no further releases.
• Four packages were published for the first time: react-for-arcgis, react-for-mappls, react-geojson and react-kml.
• react-for-mapkit now actually contains code. 0.1.3 shipped with only a LICENSE and READMEs, because the package was missing from the build script and files: ["dist"] matched nothing. If you are on 0.1.3, upgrade.
• The license identifier is now Apache-2.0. It previously read Apache2, which is not a valid SPDX identifier, so tooling reported the license as unrecognised.

Map SDK dependencies were refreshed to the newest version each declared range allows. In practice only maplibre-gl (6.3.0 → 6.4.0) and @turf/turf (7.3.5 → 7.4.0) actually moved; everything else was already current.

Packages, and the map SDK each one uses

Three providers have no map SDK in their dependencies, because their SDK is not distributed through npm at all. HERE, Apple MapKit JS and Longdo are loaded from their vendors' CDNs at runtime, so the version you get is whatever the vendor is serving.

react-for-tomtom deliberately stays on maplibre-gl 5.x while the other MapLibre-based providers are on 6.x. @tomtom-org/maps-sdk depends on maplibre-gl@^5.24.0; raising it would install two copies of MapLibre and hand the TomTom SDK a map object it was not built against.

ESM, CommonJS, and server-side rendering

These packages target a bundler. Vite, webpack, Next.js and Metro resolve them correctly, and every provider is checked rendering in a real browser before release.

Loading a provider through Node's own resolver — plain node, an SSR entry that no bundler processes, or Vitest with the node environment — is a different matter, because the underlying map SDKs are browser libraries. Measured by importing each published package in an empty project:

The other fourteen packages load both ways. These results are identical on 0.1.3, so none of it is new in 0.2.0.

Two things worth knowing:

• For SSR, import providers lazily on the client. A static top-level import of a browser-only provider will break any server render that is not bundler-processed. Our own web sample uses lazy(() => import('./providers/...')), which is why its Vite SSR build passes.
• react-for-maplibre, react-for-maptiler and react-for-tomtom advertise a CommonJS entry that cannot work, because maplibre-gl v6 dropped CommonJS. Use ESM with these three. The require condition will be removed from their exports in a future release.

The one thing that was ours

react-for-openlayers failed to load under Node ESM for a reason that had nothing to do with OpenLayers: our own source imported ol/proj without a file extension, which Node rejects as a directory import. Bundlers accept it, so it went unnoticed. Fixed in 0.2.1 — the only change, and behaviour under a bundler is unchanged.

Install

npm install @mapconductor/js-sdk-core @mapconductor/js-sdk-react @mapconductor/react-for-maplibre

Every package lives in its own repository under github.com/MapConductor.