Export GeoJsonWorkerSource and related options in package exports

[gowin20]

User Story

I'm developing MapLibre ArcGIS, the official Esri plugin for Maplibre that allows for loading of ArcGIS data layers.

Our FeatureLayer class loads data as a GeoJSONSource, but it requires a custom data loading algorithm to support our use case. Because of this, we're not using the built-in GeoJSON worker to its full capabilities, and all of the data processing is single-threaded. It's slow.

For our solution, we'd like to write our own custom source type (esriFeatureLayer), that extends GeoJSONSource and uses a custom worker to load data. The existing GeoJSONWorkerOptions of the GeoJSON worker are great, but unfortunately they are not sufficient for our use case. We need to extend the worker class and overwrite the loadData function with a fully custom implementation.

We are currently blocked from development because none of the relevant classes are exported from this package. Please export these classes publicly so that we can continue enhancing our plugin!

• GeoJSONWorkerSource
• GeoJSONSourceOptions

We also need a way to register message handlers for our custom worker script. It'd be great if there was a method on the Worker class to register custom messages programmatically:

maplibre-gl-js/src/source/worker.ts

Line 180 in 59227af

this.actor.registerMessageHandler(MessageType.updateGlobalState, async (mapId: string, params: Record<string, any>) => {

Alternatives considered

I also looked into the importScriptInWorkers method; it might be possible to implement our custom worker using this method instead. However I'm fully lost on how to do this. It seems like best practice to simply extend the GeoJSONWorkerSource, since that's the essence of what we want to do anyways.

Impact

• This will greatly improve the performance of the Maplibre ArcGIS plugin, which help MapLibre become more popular with ArcGIS customers.

[HarelM]

As you mentioned, in order to run a custom code in the worker you'd need to use importScriptInWorkers.
Exporting the classes from our point of view creates maintenance overhead from a backwards compatibility point of view as it increases the public API surface. I also don't think it will fully solve your problem.
When I rewrote the worker communication layer I added this importScript method especially for these cases.
I'll be happy to share my knowledge.
The general idea is that you add a source type with addSourceType method:

maplibre-gl-js/src/index.ts

Line 372 in 59227af

addSourceType,

And then write some code that runs in the worker thread to accommodate for this new type of source.
If you still think there are missing methods in the worker code that might need to be "more public" let's discuss.