fix(mbtiles): migrate to mbtiles 0.5.0 and sqlite3 ^3.2.0, drop EOL sqlite3_flutter_libs

[aki1770-del]

fix(mbtiles): migrate to mbtiles 0.5.0 and sqlite3 ^3.2.0, drop EOL sqlite3_flutter_libs

Closes #108

Problem

sqlite3_flutter_libs shipped version 0.6.0+eol which explicitly removes all functional code. Any project that pulls in sqlite3 ^3.x (the current latest) cannot resolve the version graph because the current pubspecs pin mbtiles: ^0.4.0, which in turn requires sqlite3 ^2.x. This creates an irreconcilable constraint for downstream users on sqlite3 v3.

Changes

flutter_map_mbtiles/pubspec.yaml

Before	After
mbtiles: ^0.4.0	mbtiles: ^0.5.0
sqlite3_flutter_libs: ^0.5.18	(removed)
(absent)	sqlite3: ^3.2.0

mbtiles 0.5.0 migrated to native assets and depends directly on sqlite3 ^3.x. The sqlite3_flutter_libs package is no longer needed — its 0.6.0+eol release ships with all code removed and a deprecation notice. Adding sqlite3: ^3.2.0 as a direct dependency satisfies the native assets requirement.

vector_map_tiles_mbtiles/pubspec.yaml

Before	After
mbtiles: ^0.4.0	mbtiles: ^0.5.0

Same mbtiles version bump. No sqlite3_flutter_libs was present here, and no direct sqlite3 dependency is needed since this package does not call sqlite3 directly.

No Dart source changes required

The mbtiles 0.5.0 public API is a drop-in replacement. No call sites in either package need updating.

---

AI-assisted — authored with Claude, reviewed by Komada.

[josxha]

@aki1770-del there are some version resolving conflicts in your pr. please have a look.

[aki1770-del]

Hi @josxha, thanks for the quick look. I've pushed a fix (56b49b1) — the CI failure was a stale mock: integration_test.mocks.dart still referenced MbTiles.dispose() which was removed in 0.5.0 (replaced by close()). The previous commit only hand-patched the import path but didn't regenerate the file. Running dart run build_runner build regenerated it correctly from the 0.5.0 API surface. Tests pass locally now.

While working through this I noticed something worth flagging for future reference: MbTilesTileProvider's primary constructor takes a raw MbTiles instance, which forces users to take a direct mbtiles dependency and align on its major version. The user in issue #108 hit exactly this — they needed sqlite3 ^3.x, which required mbtiles ^0.5.0, but the plugin pinned ^0.4.0. Every time mbtiles makes a breaking change, users who never touch MbTiles directly get caught in it.

The fromPath constructor already solves this for the common case — users who just want to load tiles from a file path don't need mbtiles in their pubspec.yaml at all. It might be worth highlighting fromPath as the recommended path in the README, and noting that the MbTiles-accepting constructor is for advanced lifecycle management only. No code change needed, just framing.

Longer term, decoupling the public API from the MbTiles type entirely would make the plugin resilient to future mbtiles breaks — but that's a bigger conversation for another time.

AI-assisted — authored with Claude, reviewed by Komada.

[josxha]

The fromPath constructor already solves this for the common case — users who just want to load tiles from a file path don't need mbtiles in their pubspec.yaml at all. It might be worth highlighting fromPath as the recommended path in the README, and noting that the MbTiles-accepting constructor is for advanced lifecycle management only.

Recommending the fromPath contstructor while having the other constructor for advanced use cases sounds good to me.

The CI complains about two issues:

1. Unused imports cause lint issues. Please ensure that there are no lints or the CI will fail.
2. The package cannot compile targeting web at the moment. The easiest solution here should be to use conditional imports with a stub implementation on web.