Skip to content

chore: version packages#295

Open
github-actions[bot] wants to merge 1 commit into
mainfrom
changeset-release/main
Open

chore: version packages#295
github-actions[bot] wants to merge 1 commit into
mainfrom
changeset-release/main

Conversation

@github-actions

@github-actions github-actions Bot commented Jul 20, 2026

Copy link
Copy Markdown
Contributor

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@youversion/platform-react-hooks@2.4.0

Minor Changes

  • 337ae5c: Fix four highlights-stack bugs surfaced by a staging session, plus a fill fade-in.

    • Invisible primary button (ui): the default button variant paired bg-background with text-primary-foreground, resolving to white-on-white in the light theme (the highlight permission dialog's Continue button was invisible). It now uses the standard bg-primary / text-primary-foreground pairing. YouVersionAuthButton pins bg-background explicitly so its neutral brand surface is unchanged.
    • Optimistic overlay dropped before the write is visible (ui): after a successful highlight write the seam hook dropped the optimistic overlay as soon as ANY refetch landed, trusting it as server truth. Under read-after-write lag (staging slowness, prod read replicas) that GET often did not yet reflect the write, so a highlight flickered out and back on apply, or a removed highlight reappeared. The overlay is now retired only once a fetch actually reflects the write (apply → the verse shows the written color; remove → the verse no longer shows the removed color); until then the overlay wins. Reset paths (chapter/version change, sign-out) release any write the server never converges on.
    • Refetch coalescing (hooks behavior change): useHighlights.createHighlight / deleteHighlight no longer refetch on each call. Direct consumers of useHighlights must now call refetch() themselves after their mutations settle. The sole in-repo consumer (useBibleReaderHighlights) now issues a single refetch after each batch settles — success or failure — so highlighting verses [2,3,5] fires two POSTs but only one GET (previously two). Batches with partial failures settle per sub-write: succeeded writes reconcile to server truth, only the failed writes' verses revert.
    • DELETE by range is unsupported (core + ui): range passage-ids (e.g. JHN.1.2-3) returned a non-2xx from staging and threw. The remove path now sends one DELETE per verse (JHN.1.2, JHN.1.3); POST/apply still collapses to ranges, which works. The HighlightsClient.deleteHighlight docstring no longer claims range delete is supported (marked unverified pending API-team confirmation). Large removals issue more DELETEs but still coalesce to a single refetch.
    • Highlight fade-in (core styles): verse highlight fills now transition their background color (~250ms, disabled under prefers-reduced-motion) instead of popping in, matching the Bible app. The selection underline and layout are untouched.

    Known/accepted trade-off (pending product sign-off): the optimistic overlay holds the locally-written value until a fetch reflects that write. A concurrent change from another device to the same verse therefore renders stale until navigation or the next write on this client. This is the deliberate cost of eliminating the flicker/ghost bugs above; documented in code comments in useBibleReaderHighlights.

Patch Changes

  • c85d8de: BibleReader highlights now wire to the highlights API behind an internal dark-launch flag; the localStorage highlight store is removed.

    • Highlights are server-only account data (YPE-1034): the temporary youversion-platform:highlights:<versionId> localStorage store is deleted outright, with no migration.
    • A new internal useBibleReaderHighlights seam fetches the current chapter's highlights via useHighlights, renders them through an in-memory optimistic overlay (reverted on write failure), and collapses contiguous verse selections into range USFMs (e.g. JHN.3.16-18) on the wire.
    • Everything is gated on an internal HIGHLIGHTS_LIVE flag (currently off) plus an authenticated session: while off or signed out, the color row is inert — no fetches, no writes, no rendered highlights. Signing out un-renders highlights immediately.
    • @youversion/platform-react-hooks now exports YouVersionAuthContext, the no-throw alternative to useYVAuth for components that must tolerate a missing auth provider (its error message already advertised the export).
    • useApiData (the fetch engine behind all data hooks, e.g. useHighlights, usePassage) fixes and behavior changes:
      • An enabled false→true flip now triggers the fetch even when the caller's deps are unchanged — previously a hook that mounted disabled (e.g. waiting on auth) never fetched after being enabled.
      • Disabling now clears data (and error) instead of keeping the last response, so stale account data cannot linger after sign-out or an auth user switch.
      • Responses are now latest-wins across refetch too: a stale in-flight request (e.g. a refetch for a previous chapter) resolving after a newer fetch no longer overwrites its data.
  • 337ae5c: Add the highlight auth flow: a color tap in BibleReader without a session or the highlights permission now stashes the intent and runs the two-path grant flow (YPE-1034, still behind the internal HIGHLIGHTS_LIVE flag).

    • Core: new DataExchangeClient.updateToken (POST /data-exchange/token, 201 → { token }, Zod-validated) plus buildDataExchangeUrl / parseDataExchangeCallback / handleDataExchangeCallback for the hosted just-in-time grant. Sign-in and data-exchange callbacks now parse granted_permissions and seed an optimistic permission cache on YouVersionPlatformConfiguration (grantedPermissions, hasPermission, saveGrantedPermissions, removeGrantedPermission); the cache is cleared on sign-out and a 401/403 invalidates it (server truth wins).
    • Hooks: new useHighlightAuthActions exposing the one-fell-swoop sign-in (requesting highlights), the just-in-time data-exchange redirect, the permission-cache reads/invalidation, and the data-exchange return handler.
    • UI: useBibleReaderHighlights now runs the state machine — pending highlights persist to sessionStorage (~10-minute expiry) to survive the redirect round-trip and apply automatically on a granted return; a just-in-time permission confirm dialog (HighlightPermissionDialog, copy matched to the native SDK) gates the data-exchange grant. Write failures route by status: 401/403 invalidates the cache, keeps the pending highlight, and re-prompts; 5xx/network reverts the optimistic overlay and discards. Apply/remove writes are serialized through a FIFO queue with per-verse ownership so overlapping operations settle to the last-issued state. Copy/share-only behavior when no auth provider is configured is unchanged.
  • Updated dependencies [337ae5c]

  • Updated dependencies [337ae5c]

    • @youversion/platform-core@2.4.0

@youversion/platform-react-ui@2.4.0

Minor Changes

  • ebddf21: BibleReader gains a controlled highlights mode (YPE-3705) for hosts that own highlight data themselves (e.g. React Native / Expo DOM hosts keeping the user token out of the WebView).
    • New BibleReader.Root props: highlights?: Highlight[] (core API shape; presence puts the highlight slice in controlled mode, latched at first mount), onVerseSelect (both modes, fires on every selection change — verses: [] whenever a non-empty selection clears, including after highlight/copy/share actions, popover dismiss, and navigation), and onHighlightApply / onHighlightRemove (controlled mode only; ignored in self-contained mode). Payloads are serializable, bridge-safe objects (BibleReaderVerseSelection, BibleReaderHighlightIntent) with always-per-verse passageIds.
    • In controlled mode the reader is a pure projection: highlights render solely from the prop (filtered by displayed version + chapter, range USFMs like JHN.3.16-18 expanded per verse), color taps emit intents and paint nothing until the host round-trips an updated prop, and neither the highlights API nor any local store is touched. No auth surface can originate from the highlight path.
    • Self-contained behavior (no highlights prop) uses the server-backed useBibleReaderHighlights path (YPE-1034), dark-launched behind HIGHLIGHTS_LIVE.
    • @youversion/platform-react-ui now re-exports the Highlight type from @youversion/platform-core.

Patch Changes

  • c85d8de: BibleReader highlights now wire to the highlights API behind an internal dark-launch flag; the localStorage highlight store is removed.

    • Highlights are server-only account data (YPE-1034): the temporary youversion-platform:highlights:<versionId> localStorage store is deleted outright, with no migration.
    • A new internal useBibleReaderHighlights seam fetches the current chapter's highlights via useHighlights, renders them through an in-memory optimistic overlay (reverted on write failure), and collapses contiguous verse selections into range USFMs (e.g. JHN.3.16-18) on the wire.
    • Everything is gated on an internal HIGHLIGHTS_LIVE flag (currently off) plus an authenticated session: while off or signed out, the color row is inert — no fetches, no writes, no rendered highlights. Signing out un-renders highlights immediately.
    • @youversion/platform-react-hooks now exports YouVersionAuthContext, the no-throw alternative to useYVAuth for components that must tolerate a missing auth provider (its error message already advertised the export).
    • useApiData (the fetch engine behind all data hooks, e.g. useHighlights, usePassage) fixes and behavior changes:
      • An enabled false→true flip now triggers the fetch even when the caller's deps are unchanged — previously a hook that mounted disabled (e.g. waiting on auth) never fetched after being enabled.
      • Disabling now clears data (and error) instead of keeping the last response, so stale account data cannot linger after sign-out or an auth user switch.
      • Responses are now latest-wins across refetch too: a stale in-flight request (e.g. a refetch for a previous chapter) resolving after a newer fetch no longer overwrites its data.
  • 337ae5c: Fix four highlights-stack bugs surfaced by a staging session, plus a fill fade-in.

    • Invisible primary button (ui): the default button variant paired bg-background with text-primary-foreground, resolving to white-on-white in the light theme (the highlight permission dialog's Continue button was invisible). It now uses the standard bg-primary / text-primary-foreground pairing. YouVersionAuthButton pins bg-background explicitly so its neutral brand surface is unchanged.
    • Optimistic overlay dropped before the write is visible (ui): after a successful highlight write the seam hook dropped the optimistic overlay as soon as ANY refetch landed, trusting it as server truth. Under read-after-write lag (staging slowness, prod read replicas) that GET often did not yet reflect the write, so a highlight flickered out and back on apply, or a removed highlight reappeared. The overlay is now retired only once a fetch actually reflects the write (apply → the verse shows the written color; remove → the verse no longer shows the removed color); until then the overlay wins. Reset paths (chapter/version change, sign-out) release any write the server never converges on.
    • Refetch coalescing (hooks behavior change): useHighlights.createHighlight / deleteHighlight no longer refetch on each call. Direct consumers of useHighlights must now call refetch() themselves after their mutations settle. The sole in-repo consumer (useBibleReaderHighlights) now issues a single refetch after each batch settles — success or failure — so highlighting verses [2,3,5] fires two POSTs but only one GET (previously two). Batches with partial failures settle per sub-write: succeeded writes reconcile to server truth, only the failed writes' verses revert.
    • DELETE by range is unsupported (core + ui): range passage-ids (e.g. JHN.1.2-3) returned a non-2xx from staging and threw. The remove path now sends one DELETE per verse (JHN.1.2, JHN.1.3); POST/apply still collapses to ranges, which works. The HighlightsClient.deleteHighlight docstring no longer claims range delete is supported (marked unverified pending API-team confirmation). Large removals issue more DELETEs but still coalesce to a single refetch.
    • Highlight fade-in (core styles): verse highlight fills now transition their background color (~250ms, disabled under prefers-reduced-motion) instead of popping in, matching the Bible app. The selection underline and layout are untouched.

    Known/accepted trade-off (pending product sign-off): the optimistic overlay holds the locally-written value until a fetch reflects that write. A concurrent change from another device to the same verse therefore renders stale until navigation or the next write on this client. This is the deliberate cost of eliminating the flicker/ghost bugs above; documented in code comments in useBibleReaderHighlights.

  • 337ae5c: Add the highlight auth flow: a color tap in BibleReader without a session or the highlights permission now stashes the intent and runs the two-path grant flow (YPE-1034, still behind the internal HIGHLIGHTS_LIVE flag).

    • Core: new DataExchangeClient.updateToken (POST /data-exchange/token, 201 → { token }, Zod-validated) plus buildDataExchangeUrl / parseDataExchangeCallback / handleDataExchangeCallback for the hosted just-in-time grant. Sign-in and data-exchange callbacks now parse granted_permissions and seed an optimistic permission cache on YouVersionPlatformConfiguration (grantedPermissions, hasPermission, saveGrantedPermissions, removeGrantedPermission); the cache is cleared on sign-out and a 401/403 invalidates it (server truth wins).
    • Hooks: new useHighlightAuthActions exposing the one-fell-swoop sign-in (requesting highlights), the just-in-time data-exchange redirect, the permission-cache reads/invalidation, and the data-exchange return handler.
    • UI: useBibleReaderHighlights now runs the state machine — pending highlights persist to sessionStorage (~10-minute expiry) to survive the redirect round-trip and apply automatically on a granted return; a just-in-time permission confirm dialog (HighlightPermissionDialog, copy matched to the native SDK) gates the data-exchange grant. Write failures route by status: 401/403 invalidates the cache, keeps the pending highlight, and re-prompts; 5xx/network reverts the optimistic overlay and discards. Apply/remove writes are serialized through a FIFO queue with per-verse ownership so overlapping operations settle to the last-issued state. Copy/share-only behavior when no auth provider is configured is unchanged.
  • 05beced: Localize BibleReader font-size/line-spacing and popover close accessibility labels via i18n.

  • 337ae5c: Rewrite the BibleReader highlights flow as an explicit xstate v5 statechart (YPE-1034 / PR-288, still behind the internal HIGHLIGHTS_LIVE flag). useBibleReaderHighlights is now a thin adapter over bibleReaderHighlightsMachine; the machine (authored with setup() and named guards/actions/actors, so it is Stately-visualizable) owns the whole flow — optimistic overlay, serialized writes with per-verse ownership, reconcile, the auth flow, and the resume-on-return path. A mermaid statechart lives in docs/highlight-flow-statechart.md. All previously-shipped invariants are preserved.

    Behavior changes:

    • Sign-in dialog first (signed out): a signed-out color tap now opens a SignInDialog (introducing the app, with an optional integrator prompt) instead of redirecting to OAuth immediately. Confirm launches the sign-in redirect requesting highlights; decline/dismiss discards the pending highlight and keeps the verse selection. The dialog's appName comes from YouVersionPlatformConfiguration.appName (falling back to "This app") and its prompt from signInPromptMessage. The hook return gains signInDialogOpen, confirmSignInDialog, and cancelSignInDialog.
    • Flag-off hides the highlights UI: when HIGHLIGHTS_LIVE is off, VerseActionPopover hides the color row and the remove (checkmark) circles entirely via a new highlightsEnabled prop — only Copy / Share remain. Previously the row still rendered while taps were inert.
    • "Vapor" fix: a deleted highlight no longer briefly reappears when a stale read-replica fetch lands after the delete settled. The reconcile step no longer retires remove-overlay entries; a removed verse is held until a reset path (scope change, sign-out, or a newer write). Apply-side convergence is unchanged. This matches the already-accepted trade-off (a concurrent same-verse edit from another device renders stale until navigation or the next write).
    • Remove-failure no longer re-prompts: a 401/403 on a remove invalidates the permission cache but no longer opens the permission dialog (there is no pending highlight to resume), resolving a documented deferred wart.
  • Updated dependencies [c85d8de]

  • Updated dependencies [337ae5c]

  • Updated dependencies [337ae5c]

    • @youversion/platform-react-hooks@2.4.0
    • @youversion/platform-core@2.4.0

@youversion/platform-core@2.4.0

Patch Changes

  • 337ae5c: Fix four highlights-stack bugs surfaced by a staging session, plus a fill fade-in.

    • Invisible primary button (ui): the default button variant paired bg-background with text-primary-foreground, resolving to white-on-white in the light theme (the highlight permission dialog's Continue button was invisible). It now uses the standard bg-primary / text-primary-foreground pairing. YouVersionAuthButton pins bg-background explicitly so its neutral brand surface is unchanged.
    • Optimistic overlay dropped before the write is visible (ui): after a successful highlight write the seam hook dropped the optimistic overlay as soon as ANY refetch landed, trusting it as server truth. Under read-after-write lag (staging slowness, prod read replicas) that GET often did not yet reflect the write, so a highlight flickered out and back on apply, or a removed highlight reappeared. The overlay is now retired only once a fetch actually reflects the write (apply → the verse shows the written color; remove → the verse no longer shows the removed color); until then the overlay wins. Reset paths (chapter/version change, sign-out) release any write the server never converges on.
    • Refetch coalescing (hooks behavior change): useHighlights.createHighlight / deleteHighlight no longer refetch on each call. Direct consumers of useHighlights must now call refetch() themselves after their mutations settle. The sole in-repo consumer (useBibleReaderHighlights) now issues a single refetch after each batch settles — success or failure — so highlighting verses [2,3,5] fires two POSTs but only one GET (previously two). Batches with partial failures settle per sub-write: succeeded writes reconcile to server truth, only the failed writes' verses revert.
    • DELETE by range is unsupported (core + ui): range passage-ids (e.g. JHN.1.2-3) returned a non-2xx from staging and threw. The remove path now sends one DELETE per verse (JHN.1.2, JHN.1.3); POST/apply still collapses to ranges, which works. The HighlightsClient.deleteHighlight docstring no longer claims range delete is supported (marked unverified pending API-team confirmation). Large removals issue more DELETEs but still coalesce to a single refetch.
    • Highlight fade-in (core styles): verse highlight fills now transition their background color (~250ms, disabled under prefers-reduced-motion) instead of popping in, matching the Bible app. The selection underline and layout are untouched.

    Known/accepted trade-off (pending product sign-off): the optimistic overlay holds the locally-written value until a fetch reflects that write. A concurrent change from another device to the same verse therefore renders stale until navigation or the next write on this client. This is the deliberate cost of eliminating the flicker/ghost bugs above; documented in code comments in useBibleReaderHighlights.

  • 337ae5c: Add the highlight auth flow: a color tap in BibleReader without a session or the highlights permission now stashes the intent and runs the two-path grant flow (YPE-1034, still behind the internal HIGHLIGHTS_LIVE flag).

    • Core: new DataExchangeClient.updateToken (POST /data-exchange/token, 201 → { token }, Zod-validated) plus buildDataExchangeUrl / parseDataExchangeCallback / handleDataExchangeCallback for the hosted just-in-time grant. Sign-in and data-exchange callbacks now parse granted_permissions and seed an optimistic permission cache on YouVersionPlatformConfiguration (grantedPermissions, hasPermission, saveGrantedPermissions, removeGrantedPermission); the cache is cleared on sign-out and a 401/403 invalidates it (server truth wins).
    • Hooks: new useHighlightAuthActions exposing the one-fell-swoop sign-in (requesting highlights), the just-in-time data-exchange redirect, the permission-cache reads/invalidation, and the data-exchange return handler.
    • UI: useBibleReaderHighlights now runs the state machine — pending highlights persist to sessionStorage (~10-minute expiry) to survive the redirect round-trip and apply automatically on a granted return; a just-in-time permission confirm dialog (HighlightPermissionDialog, copy matched to the native SDK) gates the data-exchange grant. Write failures route by status: 401/403 invalidates the cache, keeps the pending highlight, and re-prompts; 5xx/network reverts the optimistic overlay and discards. Apply/remove writes are serialized through a FIFO queue with per-verse ownership so overlapping operations settle to the last-issued state. Copy/share-only behavior when no auth provider is configured is unchanged.

Greptile Summary

This is an automated Changesets release PR that bumps all three SDK packages from 2.3.0 to 2.4.0, consuming six pending changeset files and writing the corresponding CHANGELOG entries. No source code is changed here — the actual implementation landed in the changesets being consumed.

  • Unified versioning maintained: @youversion/platform-core, @youversion/platform-react-hooks, and @youversion/platform-react-ui all move to 2.4.0 in lockstep, satisfying the repo's unified-versioning invariant. The minor bump is driven by the breaking behavior change in useHighlights (refetch coalescing) in platform-react-hooks; the other two packages follow suit.
  • Six changeset files deleted: bible-reader-controlled-mode, bible-reader-highlights-api, fix-highlights-jam-issues, highlight-auth-flow, localization-aria-labels, and xstate-highlights-flow are all consumed and removed, which is the expected lifecycle for changeset entries.
  • Workspace dependencies unchanged: Both packages/hooks and packages/ui reference sibling packages via workspace:*, so no pinned version strings needed updating.

Confidence Score: 5/5

Safe to merge — this is a mechanical version-bump PR with no source code changes; merging triggers the npm publish workflow.

All three packages are bumped in lockstep to 2.4.0, workspace cross-references remain at workspace:* (no pinned versions to drift), all six changeset files are correctly consumed, and CHANGELOG entries accurately reflect the commits. There is nothing to break here beyond what already landed in the implementation PRs.

No files require special attention.

Important Files Changed

Filename Overview
packages/core/package.json Version bumped from 2.3.0 to 2.4.0; consistent with unified versioning strategy across all packages
packages/hooks/package.json Version bumped from 2.3.0 to 2.4.0; workspace:* dependency on platform-core requires no pin change
packages/ui/package.json Version bumped from 2.3.0 to 2.4.0; workspace:* dependencies on platform-core and platform-react-hooks require no pin changes
packages/core/CHANGELOG.md New 2.4.0 section added with two patch-change entries (highlights bugs + auth flow); changelog correctly reflects the consumed changesets
packages/hooks/CHANGELOG.md New 2.4.0 section added with one minor change and two patch changes; dependency update on platform-core@2.4.0 listed
packages/ui/CHANGELOG.md New 2.4.0 section added with one minor change and five patch changes; dependency updates on platform-react-hooks@2.4.0 and platform-core@2.4.0 listed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    CS1[".changeset/bible-reader-controlled-mode.md\nui: minor"] --> R[Changesets Release Action]
    CS2[".changeset/bible-reader-highlights-api.md\nhooks: patch, ui: patch"] --> R
    CS3[".changeset/fix-highlights-jam-issues.md\ncore: patch, hooks: minor, ui: patch"] --> R
    CS4[".changeset/highlight-auth-flow.md\ncore: patch, hooks: patch, ui: patch"] --> R
    CS5[".changeset/localization-aria-labels.md\nui: patch"] --> R
    CS6[".changeset/xstate-highlights-flow.md\nui: patch"] --> R

    R -->|"highest bump = minor"| VB["Version bump: 2.3.0 → 2.4.0\n(unified across all packages)"]

    VB --> PKG1["packages/core/package.json\n2.4.0"]
    VB --> PKG2["packages/hooks/package.json\n2.4.0"]
    VB --> PKG3["packages/ui/package.json\n2.4.0"]

    VB --> CL1["packages/core/CHANGELOG.md"]
    VB --> CL2["packages/hooks/CHANGELOG.md"]
    VB --> CL3["packages/ui/CHANGELOG.md"]

    PKG1 & PKG2 & PKG3 -->|"merge → publish"| NPM["npm registry\n@youversion/platform-*@2.4.0"]
Loading

Reviews (7): Last reviewed commit: "chore: version packages" | Re-trigger Greptile

Context used:

  • Rule used - Unified versioning: All packages must maintain exa... (source)

@github-actions
github-actions Bot force-pushed the changeset-release/main branch 3 times, most recently from b166d60 to 9dbb097 Compare July 21, 2026 16:41
@cameronapak cameronapak changed the title chore: version packages [DO NOT DO YET - only after highlights prs] chore: version packages Jul 21, 2026
@github-actions github-actions Bot changed the title [DO NOT DO YET - only after highlights prs] chore: version packages chore: version packages Jul 21, 2026
@github-actions
github-actions Bot force-pushed the changeset-release/main branch 2 times, most recently from 71651a4 to 9751cfd Compare July 21, 2026 21:07
@github-actions
github-actions Bot force-pushed the changeset-release/main branch from 9751cfd to 2ee81db Compare July 22, 2026 13:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants