React SDK 0.2.0: 21 paquetes, un cambio de nombre y lo que no carga fuera de un bundler

MapConductor React SDK llegó a 0.2.0: 21 paquetes en npm, todos bajo Apache-2.0. Solo @mapconductor/react-for-openlayers está en 0.2.1; el motivo va al final.

Qué cambió

• Todos los paquetes quedaron en la misma versión. También movimos los rangos de dependencia internos entre @mapconductor/*, así que no se mezclan versiones sin querer.
• @mapconductor/react-geojson-layer pasó a llamarse @mapconductor/react-geojson. Solo cambió el nombre del paquete: GeoJSONLayer, GeoJSONLayerState, GeoJSONParser y el resto de la API siguen igual. El paquete viejo queda en npm en 0.1.3, pero ya no se actualiza.
• Publicamos cuatro paquetes por primera vez: react-for-arcgis, react-for-mappls, react-geojson y react-kml.
• react-for-mapkit por fin trae contenido. La 0.1.3 incluía solo LICENSE y README: faltaba en la lista de objetivos de compilación, así que files: ["dist"] no coincidía con nada. Si estás en 0.1.3, actualizá.
• Corregimos el identificador de licencia a Apache-2.0. Antes decía Apache2, un valor SPDX inválido, y las herramientas lo leían como “licencia no identificable”.

Actualizamos las dependencias de los SDK de mapas a lo más nuevo dentro del rango declarado. En la práctica solo se movieron dos: maplibre-gl (6.3.0 → 6.4.0) y @turf/turf (7.3.5 → 7.4.0); el resto ya estaba al día.

Los paquetes y el SDK de mapas que usa cada uno

Tres proveedores no llevan el SDK de mapas como dependencia porque no se distribuye por npm. HERE, Apple MapKit JS y Longdo se cargan en tiempo de ejecución desde el CDN del proveedor, así que la versión que realmente corre es la que ese proveedor publica.

Solo react-for-tomtom se queda en maplibre-gl 5.x. @tomtom-org/maps-sdk depende de maplibre-gl@^5.24.0; subir a 6.x metería MapLibre dos veces y le pasaría al SDK de TomTom un objeto de mapa con el que no cuenta.

ESM, CommonJS y SSR

Estos paquetes dan por sentado un bundler. Con Vite, webpack, Next.js y Metro se resuelven bien, y antes de publicar verificamos el dibujado en un navegador real para todos los proveedores.

Otra cosa es cargarlos directamente con el resolvedor propio de Node: node pelado, un punto de entrada de SSR que no pasa por el bundler, el entorno node de Vitest. El motivo es que los SDK de mapas de base son bibliotecas de navegador. La tabla sale de importar de verdad los paquetes publicados en un proyecto vacío.

Los otros 14 paquetes cargan de las dos maneras. Este mismo resultado ya se daba en 0.1.3, así que no es algo que haya aparecido con la 0.2.0.

Hay dos puntos que conviene tener presentes.

• En SSR, importá el proveedor de forma diferida del lado del cliente. Un import estático de nivel superior de un proveedor solo-navegador rompe cualquier renderizado en servidor que no pase por el bundler. El ejemplo web oficial usa lazy(() => import('./providers/...')), y por eso la compilación SSR de Vite pasa.
• react-for-maplibre, react-for-maptiler y react-for-tomtom declaran un punto de entrada CommonJS que en realidad no funciona. maplibre-gl v6 abandonó CommonJS. Usá esos tres como ESM. Quitar require de exports queda para una versión próxima.

Lo único que era culpa nuestra

Que react-for-openlayers no cargara en Node ESM no tenía nada que ver con OpenLayers. Nuestro propio código importaba ol/proj sin extensión, y Node lo rechaza como import de directorio. Los bundlers lo dejan pasar, por eso no lo vimos. Está corregido en 0.2.1: una sola línea, y el comportamiento a través de un bundler no cambia.

Instalación

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

Cada paquete vive en su propio repositorio. Mirá github.com/MapConductor.