[FEATURE] Compile for WASM

[srmncnk]

Feature Description

I want to build maplibre for web but using the wasm switch.

Describe alternatives you've considered

Mapbox has a few implementation out there but none are as good as this repository.

Additional context

Migration guide:
https://dart.dev/interop/js-interop
https://dart.dev/interop/js-interop/package-web

Errors while building for wasm:

^
../maplibre_gl_web/lib/src/interop/style/style_image_interop.dart:4:1: Error: JS interop library 'package:js/js.dart' can't be imported when compiling to Wasm.
Try using 'dart:js_interop' or 'dart:js_interop_unsafe' instead.
import 'package:js/js.dart';
^
../maplibre_gl_web/lib/src/interop/style/style_interop.dart:4:1: Error: JS interop library 'package:js/js.dart' can't be imported when compiling to Wasm.
Try using 'dart:js_interop' or 'dart:js_interop_unsafe' instead.
import 'package:js/js.dart';
^
../maplibre_gl_web/lib/src/interop/ui/map_interop.dart:5:1: Error: JS interop library 'package:js/js.dart' can't be imported when compiling to Wasm.
Try using 'dart:js_interop' or 'dart:js_interop_unsafe' instead.
import 'package:js/js.dart';
...

[josxha]

Thanks for the feature request @srmncnk. I allowed myself to shorten the error log a bit.

The current web implementation was written when js/dart interop was still in the early days. Adding support for wasm will be a bigger migration, maybe even rewrite of the maplibre_gl_web package. However, the package has currently no funding and therefore relies on pull requests by contributors. The voluntary work by the maintainers focusses at the moment on code reviews and keeping the package up-to-date. I'd be happy to review any contribution to the package via a pull request.
If you (or any other person interested in this feature) can't contribute yourself, you can offer a bounty to interest some other user to implement your feature request. If you are interested, just let me know here or on Slack. 👍

[srmncnk]

@josxha Thanks for the quick response. 👍 I'm aware of the scope, I took a whack at an old mapbox web implementation, but it's no longer maintained and Mapbox themselves don't bother with web in their new package either. So all those are plus points for you guys. JS interop in the early days was way less strict than it is now, it's kind of a surprise flutter took that turn.

I don't have resources to do it either, I'll be monitoring this though.

[josxha]

I tinkered around a bit with wasm compatible bindings for maplibre-gl-js. It's currently more a proof-of-concept and by far not feature complete but a basic map and some geojson manipulation already works fine. However I'm still evaluating if it's better to merge it into flutter-maplibre-gl or take it as a chance to start a brand new rewrite to get rid of some of the problems flutter-maplibre-gl has.

[srmncnk]

Great news @josxha, I'd be interested in seeing what you're doing.

I'd be in favour of merging it into flutter-maplibre-gl, the plus point of flutter is same codebase everywhere. I know about the caveats, been digging into the original community mapbox package myself, it's not ideal.

[josxha]

I'd be interested in seeing what you're doing.

I can make the repository public once the basics are implemented. Its purpose at the beginning was just to test the new js interop and some other things. It has currently only few features. The plan is to have a solid base for a quicker implementation of other bindings.

I'd be in favour of merging it into flutter-maplibre-gl, the plus point of flutter is same codebase everywhere. I know about the caveats, been digging into the original community mapbox package myself, it's not ideal.

I am tending to not merging it into flutter-maplibre-gl but to keep it as an alternative flutter wrapper for maplibre-gl-js and maplibre-native. Reasons for this are:

1. The current maplibre_gl_web package would get replaced with new js interop.
2. I would like to replace the current platform channel in favor of pigeon like suggested in [FEATURE] Migrate from manual method_channel to Pigeon #465 for better type safety and faster implementation.
3. There are old and undocumented workarounds I want to get rid of, for example the one removed in 525e49e.
4. Some code has unclear licensing because they contain a copyright header mentioning The Chromium Authors with a BSD-style license that isn't included in the LICENSE file.
5. I want to keep all platforms in one package to simplify the release cycle and avoid bugs like Fix: Aligned example and maplibre_gl_web pubspec versions. #476.
6. Learning from https://pub.dev/packages/mapbox_maps_flutter/changelog#200 to use data types form packages like turf of geobase.

Please take all these information with a grain of salt. These are currently just the plans I'd like to focus on. All of these points could be worked into the current maplibre-gl-js as well. I'm happy to review any pull request to flutter-maplibre-gl if anyone wants to migrate its js interop. (: