chore(deps): bump @instantdb/react from 0.22.185 to 1.0.22

[dependabot]

Bumps @instantdb/react from 0.22.185 to 1.0.22.

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[jrphilo]

Ralphie skipped this for: skip-manual-upgrade

What I saw: @instantdb/react jumps from 0.22.185 to 1.0.22 — a pre-1.0 → 1.0 release on a runtime data layer. instantdb is called out explicitly in the deps rules as security-sensitive (auth + realtime sync), and the Dependabot body links to the compare view rather than a v1 migration guide, so the breaking surface isn't summarized here.

What would unblock it: A maintainer reads the v1.0 release notes / migration guide, applies any required code or schema changes, coordinates with the paired @instantdb/core bump (#157), and verifies auth + sync behavior locally before merging.

[jrphilo]

Ralphie skipped this for: skip-needs-review

What I saw: Verification fails with 24 TypeScript errors across 6 files (components/features/{billing,settings,sidebar/atoms}/*.tsx and app/(settings)/settings/_components/sidebar.tsx). Errors are uniformly query-result fields collapsing to {} / unknown (e.g., usage.periodStart, subscription.status, user.name). Lint passes; the failure is purely the bump's interaction with the rest of the lockfile.

What I investigated:

• v1.0.0 isn't a behavioral release. Bump version to 1.0.0 instantdb/instant#2524 ("Bump version to 1.0.0", merged 2026-04-09) only edits client/packages/version/src/version.ts — the v1.0 cut is a marketing/stability milestone, not an API break. Subsequent 1.0.1–1.0.22 commits look like incremental fixes (optimistic-add fix, IndexedDB error fix, rate-limit-in-rules support, edge-runtime admin support, date-format fix). No CHANGELOG.md exists in the upstream repo and no GitHub Releases are published, so the changelog is the commit log.
• Root cause of the type errors: duplicate @instantdb/core in node_modules. Our lib/database/schema.ts builds the schema with i from @instantdb/core@0.22.155 (top-level), then lib/database/instant.ts passes that schema to init from @instantdb/react@1.0.22, which depends on @instantdb/core@1.0.22 (pinned, nested). The two core copies' schema types are incompatible, so db's query inference collapses. The fix is to bump core to 1.0.22 to match — i.e., this PR cannot be merged independently of chore(deps): bump @instantdb/core from 0.22.185 to 1.0.22 #157 (and an admin bump, see below).
• @instantdb/admin needs to bump too, but no PR exists right now. The previous admin PR (chore(deps): bump @instantdb/admin from 0.22.185 to 1.0.22 #133) was closed earlier today by @jrphilo for an unrelated lockfile-config issue — Dependabot will reopen it. npm registry confirms all three packages publish at 1.0.22 and instantdb's release pipeline versions them together, so the supported state is "bump all three in lockstep."
• Local verification cannot observe what matters for this category. lib/database/instant.test.ts and instant.server.test.ts mock @instantdb/react and @instantdb/admin entirely — they assert init plumbing, not behavior. The smoke test only hits HappyHQ's own /api/auth/status. Nothing in the local pipeline exercises InstantDB auth flows, realtime sync, transaction semantics, schema permissions, or storage — all of which are in the elevated-scrutiny surface for instantdb (called out by name in dependency-rules.md as security-sensitive).

What's still unclear: Whether v1.0's incremental fixes (especially "Clear mutations and unloaded querysubs on user change", "wait for cookie sync on auth state changes", and the SSR/hydration changes) shift any behavior our app depends on. Type checks won't catch this; only running auth + sync against a real InstantDB app will.

What would unblock it: Maintainer bumps @instantdb/{react,core,admin} to 1.0.22 together (merge #156 + #157 atomically when Dependabot reopens the admin PR, or open a single coordinated replacement PR), then verifies in a real dev environment: sign-in/sign-out, a query that returns subscription/usage data, and a db.transact write. The diff itself is three version lines; the gating work is the runtime check the loop can't perform.

[dependabot]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.