chore: switch to map libre

[ErikSin]

closes #1736

Switches from mapbox to maplibre.

The majority of the switch was a 1 to 1 mapping as map box and map libre have the same API.

In the UserToolTipMarker I changed the MarkerView to a Point Annotation. MarkerViews are meant to be interactive, and the tool tip is not something the user can interact with, so I made it a Point Annotation which is more optimized.

[awana-lockfile-bot]

src/backend/package-lock.json changes

Click to toggle table visibility

Name	Status	Previous	Current
@emnapi/core		1.9.2	1.4.3
@emnapi/runtime		1.9.2	1.4.3
@emnapi/wasi-threads		1.2.1	1.0.2
@napi-rs/wasm-runtime		0.2.12	0.2.9
@tybys/wasm-util		0.10.1	0.9.0

[socket-security]

Warning

Review the following alerts detected in dependencies.

According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.

Action	Severity	Alert  (click "▶" to expand/collapse)
Warn		Critical CVE: Arbitrary code execution in npm protobufjs CVE: GHSA-xq3m-2v4x-88gg Arbitrary code execution in protobufjs (CRITICAL) Affected versions: >= 8.0.0 < 8.0.1; < 7.5.5 Patched version: 7.5.5 From: src/backend/package-lock.json → npm/@comapeo/core@7.1.0 → npm/protobufjs@7.5.4 ℹ Read more on: This package | This alert | What is a critical CVE? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Remove or replace dependencies that include known critical CVEs. Consumers can use dependency overrides or npm audit fix --force to remove vulnerable dependencies. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/protobufjs@7.5.4. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Obfuscated code: npm entities is 91.0% likely obfuscated Confidence: 0.91 Location: Package overview From: src/backend/package-lock.json → npm/@comapeo/core@7.1.0 → npm/entities@4.5.0 ℹ Read more on: This package | This alert | What is obfuscated code? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Packages should not obfuscate their code. Consider not using packages with obfuscated code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/entities@4.5.0. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

View full report

[awana-lockfile-bot]

package-lock.json changes

Click to toggle table visibility

Name	Status	Previous	Current
@hyperswarm/secret-stream		6.9.1	6.8.1
@mapbox/mapbox-gl-style-spec		14.21.0	14.22.0
@maplibre/maplibre-react-native		-	10.4.2
@rnmapbox/maps		10.1.42	-
@sqlite.org/sqlite-wasm		3.51.2-build8	3.51.2-build9
@turf/along		6.5.0	-
@turf/bearing		6.5.0	7.3.4
@turf/destination		6.5.0	-
@turf/length		6.5.0	-
@turf/line-intersect		6.5.0	-
@turf/line-segment		6.5.0	-
@turf/nearest-point-on-line		6.5.0	7.3.4
bare-ansi-escapes		2.2.3	-
bare-assert		1.2.0	-
bare-inspect		3.1.4	-
bare-type		1.1.0	-
debounce		1.2.1	-
geojson-rbush		3.2.0	-
noise-handshake		4.2.0	4.1.0
typebox		1.1.16	1.1.32

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	npm/​@​comapeo/​default-categories@​1.0.1
	npm/​sentry-offline-transport-better-sqlite@​1.1.2
	npm/​@​types/​better-sqlite3@​7.6.13
	npm/​@​tsconfig/​node16@​16.1.1
	npm/​@​digidem/​types@​2.1.0
	npm/​rollup@​3.5.0
	npm/​rollup-plugin-esbuild@​6.2.1
	npm/​patch-package@​8.0.0
	npm/​@​types/​node@​20.19.4 ⏵ 20.8.6	+1		+1
	npm/​@​types/​debug@​4.1.12 ⏵ 4.1.9	+1		+6
	npm/​@​rollup/​plugin-esm-shim@​0.1.8
	npm/​@​rollup/​plugin-json@​6.0.1
	npm/​debug@​3.2.7 ⏵ 4.4.1	+1		+1
	npm/​@​rollup/​plugin-alias@​5.1.0
	npm/​@​rollup/​plugin-node-resolve@​15.2.3
	npm/​magic-string@​0.30.8
	npm/​@​sentry/​node@​9.28.0
	npm/​@​rollup/​plugin-commonjs@​25.0.7
	npm/​typescript@​5.2.2
	npm/​prettier@​3.0.3
	npm/​@​sentry/​rollup-plugin@​3.5.0

View full report

[cimigree]

Looks good and works great. Only two small things.

1. It looks like we will still need the MAPBOX_ACCESS_TOKEN when doing E2E tests.
   Unless there is some kind of
   We need to document that somewhere somehow so it doesn't get removed accidentally.

Or, do you know if there is a MapLibre-hosted or open style URL that could replace the Mapbox one in the E2E fallback? This possibly?

2. I am seeing repeated logs in the console:
   LOG MapLibre [info] Request failed due to a permanent error: Canceled {"level": "warning", "message": "Request failed due to a permanent error: Canceled ", "tag": "Mbgl-HttpRequest"}
   especially when I move around on the map.

It doesn't appear to affect functionality but wanted to make sure you knew about it.

[ErikSin]

Or, do you know if there is a MapLibre-hosted or open style URL that could replace the Mapbox one in the E2E fallback? This possibly?

We still use the mapbox map as the main default map. We use maplibre to render the map, but the map tiles come from mapbox.

[achou11]

I am seeing repeated logs in the console:
LOG MapLibre [info] Request failed due to a permanent error: Canceled {"level": "warning", "message": "Request failed due to a permanent error: Canceled ", "tag": "Mbgl-HttpRequest"}
especially when I move around on the map.

already posted this elsewhere but for posterity...

tl;dr - basically, any mapbox assets (e.g. tiles, glyphs, etc) will fail to load on the map for devices running e2e tests on browserstack, due to using a hardcoded mapbox style url for the map style.

None of the asset urls that the hardcoded mapbox style url uses will include the access token with them, causing auth errors from mapbox and thus failing to load the assets. usually if you're using a mapbox sdk (like we were before), you set the access token to use client-side so that any asset requests the library makes will include it. however, since we're switching to maplibre, it doesn't do that and there's no way to update the urls requested to include it in the mobile sdks.

for context, our map server usually transforms the urls to include the access token if available, so the auth errors aren't an issue when using the style url coming from the map server.

I don't think this is really a blocker for the PR in any sense since the e2e tests don't test anything related to the underlying map that's rendered. the ideal solution is to avoid the hardcoding of the style url used, but I'm assuming the browserstack issue related to the embedded http server still prevents that. otherwise, you could opt for a different hardcoded online style url like the maplibre demotiles one, but it won't really matter for the purposes of the e2e tests in the end.