[Bug/FeatureRequest] Change map types based on `mapLib`

[tordans]

Description

Right now, the library always uses Mapbox Types.

Why…

• Right now, the types are more or less in sync, but that will likely change with every comming update
• Right now, it is pretty hard to get to the maplibre types from within VS Code – one has to manually open the generated types.g file in node_modules (at least that is the only way I know…).

Expected Behavior

The library uses the types of the given mapLib, meaning the maplibre types for mapLib={maplibregl}

Steps to Reproduce

• In https://github.com/visgl/react-map-gl/blob/master/src/components/map.tsx#L13 only Mapbox Types are importet
• In https://github.com/visgl/react-map-gl/blob/master/src/components/map.tsx#L29 it says mapLib?: any; – This might need to change to explicitly allow some libraries?

Environment

• Framework version: master
• Map library: maplibre

Logs

No response

[Pessimistress]

I don't think that's a thing in TypeScript.

Best we can do is to export a different Map component that explicitly supports Maplibre.

[manuelroth]

I just found this issue, because I experienced it using the cooperativeGestures option in MapLibre (in MapLibre it can be a boolean or GestureOptions object whereas in Mapbox GL JS it can be only a boolean). I would therefore also support @Pessimistress suggestion of exporting a separate Map component for MapLibre. @Pessimistress would this be a big change to make?- I am new to react-map-gl code base. Where does this need to be added?

[jpoehnelt]

Seems this could possibly be handled with some generics?

[smnbbrv]

First of all thanks to all authors and contributors of this project.

I think the question is rather - is it possible at all to support two different libraries with one react middleware? Isn't it just better to have a separate fork implementation for maplibre? The forks are going to have different API / signatures and although they started at one point it's almost inevitable that the engines diverge after some time. This would be a heavy task for a library maintainer to keep in mind both libs at once.

The current setup (webpack patching, externals, etc) is something that is hard to accept for a library that just provides react bindings to another library. For some projects it is simply impossible. In other words, to my taste, the claimed support of maplibre is not a support.

The question I'd like to ask maintainers - is this on the roadmap to provide a real support of maplibre?

[Pessimistress]

This will be addressed in v7.1, please use #2161 to track the progress.