MapConductorLos módulos del MapConductor React SDK se actualizaron: 19 de los 21 paquetes en npm se movieron. La mayor parte es mantenimiento de dependencias, pero dos correcciones alrededor de MapLibre atienden fallas cuya causa cuesta encontrar cuando aparecen.
Las versiones quedaron a propósito sin igualar. react-for-maplibre y react-for-openlayers están en 0.2.2; react-icons y react-kml se quedan donde estaban; el resto está en 0.2.1. A diferencia de 0.2.0, ya no ponemos todos los paquetes en el mismo número: subir un paquete cuyo contenido no cambió solo le dice a quien actualiza que "algo cambió".
El mapa queda en color de fondo, y nada lanza un error
De esto trata react-for-maplibre 0.2.2.
MapLibre GL JS v6 distribuye su Web Worker como archivo aparte y arma la URL a partir de su propio import.meta.url. Al pasar por un bundler ese valor se congela en tiempo de compilación —una ruta file:// con Rspack, el destino del prebundle con Vite— mientras que el archivo real del worker no se emite en ningún lado. La resolución falla.
Lo incómodo es que la falla no lanza nada. Se crea en silencio algo como new Worker("") y el mapa se detiene sin emitir una sola solicitud de tesela. Lo que se ve es un mapa hecho de color de fondo. Si el panel de red muestra cero solicitudes .pbf, ese es el síntoma.
0.2.2 incluye un worker autocontenido en el paquete y lo registra automáticamente al crear el primer mapa. No hay nada que configurar. Se comporta igual con Vite y con webpack / Rspack, tanto en dev como en compilaciones de producción.
Hay una excepción: servir el worker desde una URL propia (un CDN compartido, o una compilación que ya lo emite). Llame a setMapLibreWorkerUrl(url) antes de crear el primer mapa y el worker incluido se omite, sin siquiera descargarse.
import { setMapLibreWorkerUrl } from '@mapconductor/react-for-maplibre';
setMapLibreWorkerUrl('https://cdn.example.com/maplibre-worker.mjs');Algo que conviene esperar: el servidor de desarrollo de Vite pasa el worker incluido por su cadena de transformación, lo que inyecta un import de /@vite/client e infla el archivo (de unos 478 KB a unos 2,8 MB). Se ve alarmante y no cambia nada del comportamiento; las compilaciones de producción lo emiten como un recurso común.
Entregar el worker como Blob URL no funciona en v6. El worker arranca sin error y aun así no emite ninguna solicitud de tesela. Hay que servirlo como archivo real.
onMapLoaded nunca se disparaba
También react-for-maplibre 0.2.2.
MapLibreProvider.initialize() espera map.once('load') antes de crear el controlador. Para cuando el controlador existe, la carga ya ocurrió, así que el on('load') que engancha setupEventListeners no puede volver a dispararse.
La verificación de "ya inicializado" en el constructor debía cubrir ese caso, y no lo hacía: tanto loaded() como isStyleLoaded() devuelven false justo después de la carga. El isStyleLoaded() de MapLibre v6 llama a Style.loaded(), que espera a que termine cada tileManager.
Corregido en 0.2.2. Si usaba onMapLoaded, hasta ahora nunca se había llamado.
js-sdk-core 0.2.1: el Service Worker se caía cuando había demasiados íconos distintos
Los íconos de marcador llegan al Service Worker de teselas como mapas de bits. Se juntaban de a uno y se enviaban todos al final, así que con más íconos distintos de los que el caché puede guardar, los primeros ya estaban liberados cuando salía el envío. Clonar estructuralmente un ImageBitmap liberado lanza DataCloneError, y eso se lleva puesta toda la registración del Service Worker.
Sin registración no llega ni una tesela, así que lo que se ve es un mapa que no aparece. Y solo se reproduce cuando la cantidad de íconos distintos supera el tamaño del caché: esa clase de falla que anda en tu máquina y se detiene en producción.
La corrección no es agrandar el caché. Es la propiedad: ahora el envío lleva copias propias y las libera una vez que el envío retornó. Lo que es del caché queda intacto.
TomTom ya no carga un segundo MapLibre
En 0.2.0, react-for-tomtom era el único módulo retenido en maplibre-gl 5.x, porque @tomtom-org/maps-sdk dependía de maplibre-gl@^5.24.0. Pasar a 6.x habría instalado dos copias de MapLibre y entregado al SDK de TomTom un objeto de mapa que no esperaba.
TomTom pasó a maplibre-gl@^6.4.0 en 0.51.5. react-for-tomtom 0.2.1 lo acompaña con ^6.6.0. Ahora comparte un solo MapLibre con react-for-maplibre y react-for-maptiler, y la advertencia de 0.2.0 ya no aplica.
Un efecto secundario: react-for-tomtom ahora carga bajo el resolvedor ESM de Node. En 0.2.0 no lo hacía, y la razón era que "lee maplibre-gl/package.json, que Node solo carga con un atributo de importación". Medido importando los paquetes publicados en un proyecto vacío.
import | require() | |
|---|---|---|
react-for-tomtom 0.2.0 | no | no |
react-for-tomtom 0.2.1 | yes | no |
require() sigue fallando porque maplibre-gl v6 es solo ESM y no declara entrada CommonJS: la misma razón que en react-for-maplibre y react-for-maptiler. Use esos tres por ESM.
Cuatro versiones 0.2.1 sin cambios de código
Las versiones 0.2.1 de js-sdk-react, react-geojson, react-heatmap y react-marker-clustering entregan el mismo JavaScript que 0.2.0. Lo que se movió son datos de compilación que viajan dentro del paquete y que una compilación web nunca lee. No hay urgencia en tomarlas, y tampoco hay daño en hacerlo.
Actualizaciones de los SDK de mapas
Llevados a la versión más nueva dentro del rango declarado. Estos son los que se movieron.
| Dependencia | 0.2.0 | Ahora |
|---|---|---|
mapbox-gl | ^3.15.0 | ^3.29.0 |
maplibre-gl | ^6.0.0 | ^6.6.0 |
cesium | ^1.131.0 | ^1.144.0 |
ol | ^10.2.1 | ^10.10.0 |
@arcgis/core | ^5.1.16 | ^5.1.20 |
@tomtom-org/maps-sdk | ^0.51.0 | ^0.51.5 |
azure-maps-control | ^3.7.0 | ^3.7.4 |
@turf/turf | ^7.3.5 | ^7.4.0 |
Tres quedaron igual —leaflet ^1.9.4, @googlemaps/js-api-loader ^2.1.1 y mappls-web-maps ^3.8.1— porque aguas arriba no hubo movimiento. Las peerDependencies de React siguen en ^18.0.0 || ^19.0.0; solo cambió la versión de desarrollo (19.2.7 → 19.2.8).
Los paquetes y sus SDK de mapas
HERE, Apple MapKit JS y Longdo no llevan un SDK de mapas como dependencia porque esos SDK no se distribuyen por npm. Se cargan del CDN del proveedor en tiempo de ejecución, así que la versión que realmente corre es la que el proveedor esté sirviendo.
Cómo actualizar
npm install @mapconductor/js-sdk-core@latest @mapconductor/js-sdk-react@latest \ @mapconductor/react-for-maplibre@latest
js-sdk-core también quedó en 0.2.1. Lleva la corrección del Service Worker de arriba, así que si usa muchos íconos de marcador distintos, tómelo.
ESM, CommonJS y SSR se comportan igual que en 0.2.0, salvo react-for-tomtom arriba. La tabla completa de qué carga y qué no fuera de un bundler está en el artículo de React SDK 0.2.0. Cada paquete vive en su propio repositorio: vea github.com/MapConductor.