feat(sqlite-plugin): add adapter-helpers subpath export#226
feat(sqlite-plugin): add adapter-helpers subpath export#226Mohamed-kassim wants to merge 1 commit intocallstackincubator:mainfrom
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
Mohamed-kassim
changed the title
V3RON
left a comment
V3RON
left a comment
There was a problem hiding this comment.
I think we should create a separate entry point for these helpers, since they are currently being pulled into production app builds (they are not gated by the if statement below).
For example, we could define a new entry point like @rozenite/sqlite-plugin/adapter-helpers and export them from there. This would eliminate any risk of leakage.
Mohamed-kassim
changed the title
Sorry for the delay, I missed your reply. |
Co-authored-by: Cursor <cursoragent@cursor.com>
Mohamed-kassim
force-pushed
the
feat/sqlite-plugin-internals-export
branch
from
f343a92 to
2ddac77
Compare
|
This approach doesn't work quite as expected. Vite crashes when trying to run vite-require-plugin because it generates multiple outputs where only one is expected. Even after fixing that, some extra files still end up in dist/react-native, like the JS bundle for the DevTools UI. To keep things simple for now, I decided to go with the same approach we already use for other plugin exports and just provide mocks in production. It's not perfect, but it should work well enough until I get a chance to revisit the Vite plugin setup. See #259 |
#259) ## Why When building a custom SQLite adapter for Rozenite (e.g. a driver not covered by the built-in Expo SQLite adapter), developers need to parse, classify, and normalise SQL statements themselves — and decode bridge-encoded values returned over the JS/native boundary. The relevant utilities already exist in `shared/sql` and `shared/bridge-values`, but they were not exported from the package, forcing consumers to either duplicate the logic or reach into internal paths. ## What Exports the following helpers from the `react-native` entry-point of `sqlite-plugin`: **`shared/sql`** - `SqlStatementSegment` (type) - `classifySqlStatement` - `normalizeSingleStatementSql` - `splitSqlStatements` - `statementReturnsRows` **`shared/bridge-values`** - `decodeSqliteBridgeValue` - `formatSqliteError` ## Approach An earlier attempt at this was made in #226, which tried to generate a new dedicated entry-point for these helpers. That approach turned out to be flaky, so for the time being the same pattern used for all other exported functions is applied here: `let` declarations assigned via inline `require()` calls that Metro can statically analyse, with passive no-op mocks assigned in the `else` branch for production/web/SSR builds. This ensures the helpers are completely tree-shaken out of production bundles.
2 participants
Summary
We’re integrating Rozenite SQLite inspector with non-Expo SQLite drivers (e.g. react-native-nitro-sqlite). The plugin already has shared SQL normalization / statement classification / bridge decode / error formatting helpers, but they were not available on a stable public subpath.
This PR exposes those helpers via a dedicated subpath:
@rozenite/sqlite-plugin/adapter-helpersThis keeps helper code out of the main package entry and avoids leaking it into production builds that only use the core plugin APIs.
Implementation notes
src/react-native/adapter-helpers.tsto re-export existing shared helpers fromsrc/shared/sqlandsrc/shared/bridge-values../adapter-helperstopackages/sqlite-plugin/package.jsonexports.vite.config.tsso dist emits:dist/react-native/adapter-helpers.jsdist/react-native/adapter-helpers.cjsdist/react-native/adapter-helpers.d.tsQuestion for maintainers
We also have a small adapter that wires react-native-nitro-sqlite into
createSqliteAdapter, using these same helpers. Are you open to follow-up PRs that add additional first-party adapters (e.g. Nitro)?Thanks for reviewing.