[joker-777]

• On Android (JSI) and Windows, the build compiles SQLite into the app. It came from the @nozbe/sqlite package, which holds SQLite 3.46.0 from June 2024 and hasn't been updated since. That package is an unmodified copy of SQLite's official single-file source (the "amalgamation").
• The 3.54.1 amalgamation now lives in native/sqlite, and both builds compile it from there. The build script copies it into the package. The download was checked against the SHA3-256 hash on sqlite.org, and README.md there records the version, source and update steps.
• The @nozbe/sqlite dependency is removed. The published package stays about 3 MB, since it now carries the source that the old dependency used to bring in.
• CMakeLists.txt: the build looks for its own test app by checking for @nozbe/simdjson instead of @nozbe/sqlite. The cache counter is bumped, so CMake builds from scratch.
• WatermelonDB.vcxproj: WatermelonSqliteDir now defaults to native/sqlite, the same way WatermelonJsiSharedDir points to native/shared. Consumers can still override it.
• WatermelonDB.vcxproj also defines SQLITE_UWP. SQLite 3.53.0 dropped Windows RT support, and 3.54.0 documents -DSQLITE_UWP=1 for UWP apps. SQLITE_OS_WINRT stays defined for older SQLite versions.
• New native/windows/WatermelonDB/sqlite3_uwp.h, force-included only into sqlite3.c. SQLite 3.53 dropped its CreateFile2 path, and 3.54 still calls the desktop-only CreateFileW and AreFileApisANSI with SQLITE_UWP (reported upstream in this forum thread, unfixed). In Windows Store builds, the header routes CreateFileW to CreateFile2 with SQLite 3.46's flag mapping, and makes AreFileApisANSI return true, as 3.46 did. sqlite3.c stays unmodified.
• iOS and the non-JSI Android bridge are unchanged; they use the system SQLite.

Verification:

• sqlite3.c compiles with NDK 27.1 for arm64 at -Os.
• yarn build puts the SQLite files under dist/native/sqlite, and dist/package.json no longer lists @nozbe/sqlite.
• Windows: the fork's CI has the Windows job disabled (if: false, the port is unmaintained upstream), so it was checked with one-off runs on windows-2022 (MSVC 14.44, Windows SDK 10.0.26100) in Windows Store mode (WINAPI_FAMILY=WINAPI_FAMILY_APP, as WatermelonDB.vcxproj builds):
  • Without the header, 3.54.1 fails on CreateFileW and AreFileApisANSI (run).
  • With this PR's files, sqlite3.c compiles at /W4 without errors or warnings. It no longer references CreateFileW, uses CreateFile2, and every Windows import is in WindowsApp.lib, the set Store apps may call (run).
  • A smoke test of the same header passed: 200,000 rows, WAL mode, temp files, a checkpoint and a shared in-memory database (run). It ran as a normal desktop program, not inside a Store app's sandbox.
  • The full WatermelonDB.vcxproj / react-native-windows build was not run.
• This PR's Android CI job builds the JSI library and runs the adapter tests on an emulator.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

Removing @nozbe/sqlite breaks clean Windows builds because the Windows project still references its sources; migrate those references to vendored SQLite or retain the dependency.

1 open issue

• Removing @​nozbe/sqlite breaks clean Windows builds · New

What changed in this PR

This PR updates WatermelonDB’s bundled Android JSI SQLite from 3.46.0 to 3.54.1 and moves its source into the repository. iOS and the non-JSI Android bridge remain unchanged.

Changes:

• Switch Android CMake to local SQLite sources, update test-app detection, and bump the cache counter.
• Remove the @nozbe/sqlite dependency and lockfile entry.
• Document the bundled version, source verification, and update procedure.

File	Description
yarn.lock	Removes the @nozbe/sqlite lockfile entry.
package.json	Removes the @nozbe/sqlite dependency.
native/​android-jsi/​src/​main/​cpp/​CMakeLists.txt	Builds local SQLite sources and updates dependency discovery.
native/​android-jsi/​sqlite/​sqlite3ext.h	Adds the bundled SQLite extension API header.
native/​android-jsi/​sqlite/​README.md	Records the version, checksum, source, and update steps.
docs-website/​docs/​docs/​Advanced/​ProTips.md	Points users to the bundled-version README.
CHANGELOG-Unreleased.md	Announces the Android JSI SQLite upgrade.

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

The Windows Store project still defines SQLITE_OS_WINRT instead of SQLITE_UWP, causing the new SQLite amalgamation to select desktop-only APIs and break the UWP build.

1 open issue

• Update the Windows Store project to define SQLITE_UWP · New

1 resolved since last review

• Removing @​nozbe/sqlite breaks clean Windows builds

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

The SQLite upgrade and SQLITE_UWP changes lack Windows/UWP build and adapter validation, while Windows CI is disabled.

No open issues 🎉

1 resolved since last review

• Update the Windows Store project to define SQLITE_UWP

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

Windows/UWP compatibility requires MSVC and Windows SDK validation because CreateFileW and AreFileApisANSI are referenced unconditionally, reported MinGW checks fail, and Windows CI is disabled.

No open issues 🎉

_{Review effort: Balanced}

[joker-777]

Checked the Windows Store build with Microsoft's compiler: a one-off job on windows-2022 (MSVC 14.44, Windows SDK 10.0.26100) compiled native/sqlite/sqlite3.c with /DWINAPI_FAMILY=WINAPI_FAMILY_APP, the mode WatermelonDB.vcxproj builds in (AppContainerApplication). Run, scratch branch since deleted.

• With SQLITE_UWP (this PR): fails. CreateFileW and AreFileApisANSI are undeclared.
• Without it: fails on the same two plus HeapValidate.

So SQLite 3.54.1 does not compile for this Windows Store project in either configuration, while 3.46.0 does. MinGW reports the same. Not fixed yet; the options are being discussed.

🤖 Generated with Claude Code

[Copilot]

🟢 Approval recommended

The bundled SQLite migration has no active review issues.

No open issues 🎉

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

The Windows project and UWP file-API shim need maintainer validation through a full react-native-windows build and Store-sandbox database/WAL testing, as existing evidence covers only standalone compilation and desktop smoke tests.

No open issues 🎉

_{Review effort: Balanced}