feat(macos): support native SQLite packages - #298
Open
samuelscheit wants to merge 11 commits into
Open
Conversation
The benchmark reset flow used the module-scoped largeDb variable as a proxy for whether the on-disk database existed. SQLite files survive app restarts while that variable does not, so a fresh runtime reopened an existing large database and unconditionally attempted to create Test again. This surfaced as "table Test already exists" before the benchmark could run.\n\nKeep the benchmark connection open for the current runtime and rebuild its schema transactionally on every reset. The shared schema helper drops the old Test table before recreating the expected STRICT table, preserving deterministic benchmark data whether the database is new, persisted from a previous launch, or reused in the same session. The misleading user-database error label is corrected as well.\n\nAdd a native regression test that begins with an incompatible existing Test table and verifies that the reset helper replaces it with the full benchmark schema. Register it with the unit suite so the persisted-schema lifecycle is covered without inserting 300,000 benchmark rows during tests.
Add a first-class React Native macOS example workspace that reuses the shared SQLite, TypeORM, sqlite-vec, console, and benchmark flows while providing a macOS-safe navigation implementation and platform-specific Metro/Babel configuration. Wire CocoaPods, autolinking, generated native registration, app sandbox configuration, database storage under Application Support, and sqlite-vec opt-in support for macOS. Patch react-native-get-random-values so it registers correctly in the macOS new-architecture build. Replace the legacy thread-unsafe SQLite performance toggle with a single thread-safe configuration. Async operations execute on Nitro worker threads, so SQLite must retain mutex support to avoid crashes during repeat and concurrent test runs. Add matching CI coverage: a cached macOS build workflow for pushes and pull requests, plus a PR integration workflow that builds the app, starts Metro on an ephemeral port, launches the compiled app, and waits for its structured test report. The runner propagates app and Metro startup failures, validates results, and reliably tears down child process groups. React Native Harness currently supports Android and iOS targets, but has no macOS platform runner or desktop-process lifecycle integration. The macOS workflow therefore uses a small explicit result transport instead of the Harness WebSocket bridge: the runner creates a loopback HTTP endpoint, supplies its unguessable URL and Metro port through the launched app's environment, and the AppDelegate exposes the URL only as a test initial prop. The test-only macOS root runs the shared Mocha suite and posts its structured result to that endpoint. This preserves normal app behavior while giving CI a deterministic completion signal and actionable test failures; it can be replaced by the standard Harness bridge once macOS support exists upstream. Keep release lockfile maintenance in sync with the new macOS Pods workspace, share the test registration used by the UI and CI runner, and document macOS installation, launch, database-location, and vector-search workflows.
Restore the original performance_mode selector and its mode 1 default, including the thread-unsafe SQLite compile flag and the existing mode 2 thread-safe branch. This preserves the Apple build behavior and local configuration point that existed before macOS support was added. Regenerate the iOS and macOS Pod lockfiles so CocoaPods consumes the restored podspec consistently in local builds, release lockfile maintenance, and CI.
Expose the Android, iOS, and macOS harness workflows through workflow_dispatch so maintainers can validate any platform without waiting for a pull request event.\n\nThe existing pull_request path filters remain unchanged, preserving the current automatic CI scope while enabling on-demand reruns and investigation from the Actions UI.
Replace the hard-coded legacy performance selector with the validated NITRO_SQLITE_THREADSAFE CocoaPods setting. The setting accepts only 0 or 1 and defaults to 0, retaining the existing iOS build configuration. Opt the React Native macOS example into SQLITE_THREADSAFE=1 because its async APIs execute on Nitro worker threads. This avoids unsafe concurrent SQLite access while leaving iOS behavior unchanged. Regenerate the macOS Podfile lockfile and document how downstream Apple applications can opt into mutex support before installing Pods. Validation: ruby podspec syntax check; macOS and iOS pod installs; generated Debug/Release xcconfig checks for macOS=1 and iOS=0; clean macOS Debug build; four CI-style macOS runner passes with 69 passing tests each; root typecheck; non-mutating ESLint checks; Prettier check; invalid configuration rejection.
Align every handwritten SQLite helper and hybrid object with Nitrogen's generated margelo::nitro::rnnitrosqlite namespace. This removes the stale parallel namespace and broad using declarations that made the generated macOS bindings and native implementation refer to different types. Resolve internal headers relative to their owning directory so CocoaPods cannot accidentally select op-sqlite's similarly named headers. Correct SQLite column metadata comparisons so declared BOOLEAN, FLOAT, INTEGER, TEXT, and BLOB types map to their intended Nitro result representations. Expose the package source through the react-native export condition. React Native macOS can now resolve the local package without falling back from a missing prebuilt CommonJS artifact during development. Validated with package type checking and build, a clean Metro macOS bundle, CocoaPods installation, an arm64 macOS Xcode build, and the ORM benchmark's native Column, Objects, Types, and unsupported Arrays paths.
Member
|
Thanks for the PR! This is huge! 馃帀 I'm going to extract some parts of this PR into smaller pieces, to easier merge and review it. I'll post a plan on how i'm going to work with this here in a bit. |
This was referenced Sep 10, 2026
chrispader
changed the base branch from
main
to
codex/align-native-namespaces
September 10, 2026 19:14
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The native packages do not register for macOS, and their Apple initialization uses the mobile database directory. This PR adds macOS platform registration and stores desktop databases in Application Support under the application's bundle identifier.
The library keeps the merged thread-safety and performance configuration, operation serialization, and existing iOS database behavior. Core and sqlite-vec podspecs, autolinking, and platform documentation are included here. The macOS deployment range remains tracked in #336.
Review the dependent changes in this order: native C++ alignment in #350, this library PR, the desktop example in #351, then integration testing and CI in #352. The upstream
codex/macos-librarybranch mirrors this PR so the example can target it.The independent extractions are native test triggers in #346, persisted benchmark reset in #347, and the React Native source export in #348. The column metadata correction stays in the existing #313. The unrelated Jest removal is omitted.
The complete desktop stack passed a macOS Debug build and an integration run with 83 passing tests.
Fixes #338. Fixes #333. Partially addresses #34.