chore: version packages#295
Open
github-actions[bot] wants to merge 1 commit into
Open
Conversation
github-actions
Bot
force-pushed
the
changeset-release/main
branch
3 times, most recently
from
July 21, 2026 16:41
b166d60 to
9dbb097
Compare
github-actions
Bot
force-pushed
the
changeset-release/main
branch
2 times, most recently
from
July 21, 2026 21:07
71651a4 to
9751cfd
Compare
github-actions
Bot
force-pushed
the
changeset-release/main
branch
from
July 22, 2026 13:18
9751cfd to
2ee81db
Compare
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.
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.
defaultbutton variant pairedbg-backgroundwithtext-primary-foreground, resolving to white-on-white in the light theme (the highlight permission dialog's Continue button was invisible). It now uses the standardbg-primary/text-primary-foregroundpairing.YouVersionAuthButtonpinsbg-backgroundexplicitly so its neutral brand surface is unchanged.useHighlights.createHighlight/deleteHighlightno longer refetch on each call. Direct consumers ofuseHighlightsmust now callrefetch()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.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. TheHighlightsClient.deleteHighlightdocstring 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.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.
youversion-platform:highlights:<versionId>localStorage store is deleted outright, with no migration.useBibleReaderHighlightsseam fetches the current chapter's highlights viauseHighlights, 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.HIGHLIGHTS_LIVEflag (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-hooksnow exportsYouVersionAuthContext, the no-throw alternative touseYVAuthfor 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:enabledfalse→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.data(anderror) instead of keeping the last response, so stale account data cannot linger after sign-out or an auth user switch.refetchtoo: 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
highlightspermission now stashes the intent and runs the two-path grant flow (YPE-1034, still behind the internalHIGHLIGHTS_LIVEflag).DataExchangeClient.updateToken(POST /data-exchange/token, 201 →{ token }, Zod-validated) plusbuildDataExchangeUrl/parseDataExchangeCallback/handleDataExchangeCallbackfor the hosted just-in-time grant. Sign-in and data-exchange callbacks now parsegranted_permissionsand seed an optimistic permission cache onYouVersionPlatformConfiguration(grantedPermissions,hasPermission,saveGrantedPermissions,removeGrantedPermission); the cache is cleared on sign-out and a 401/403 invalidates it (server truth wins).useHighlightAuthActionsexposing the one-fell-swoop sign-in (requestinghighlights), the just-in-time data-exchange redirect, the permission-cache reads/invalidation, and the data-exchange return handler.useBibleReaderHighlightsnow runs the state machine — pending highlights persist tosessionStorage(~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-react-ui@2.4.0
Minor Changes
BibleReader.Rootprops: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), andonHighlightApply/onHighlightRemove(controlled mode only; ignored in self-contained mode). Payloads are serializable, bridge-safe objects (BibleReaderVerseSelection,BibleReaderHighlightIntent) with always-per-versepassageIds.JHN.3.16-18expanded 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.highlightsprop) uses the server-backeduseBibleReaderHighlightspath (YPE-1034), dark-launched behindHIGHLIGHTS_LIVE.@youversion/platform-react-uinow re-exports theHighlighttype 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.
youversion-platform:highlights:<versionId>localStorage store is deleted outright, with no migration.useBibleReaderHighlightsseam fetches the current chapter's highlights viauseHighlights, 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.HIGHLIGHTS_LIVEflag (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-hooksnow exportsYouVersionAuthContext, the no-throw alternative touseYVAuthfor 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:enabledfalse→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.data(anderror) instead of keeping the last response, so stale account data cannot linger after sign-out or an auth user switch.refetchtoo: 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.
defaultbutton variant pairedbg-backgroundwithtext-primary-foreground, resolving to white-on-white in the light theme (the highlight permission dialog's Continue button was invisible). It now uses the standardbg-primary/text-primary-foregroundpairing.YouVersionAuthButtonpinsbg-backgroundexplicitly so its neutral brand surface is unchanged.useHighlights.createHighlight/deleteHighlightno longer refetch on each call. Direct consumers ofuseHighlightsmust now callrefetch()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.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. TheHighlightsClient.deleteHighlightdocstring 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.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
highlightspermission now stashes the intent and runs the two-path grant flow (YPE-1034, still behind the internalHIGHLIGHTS_LIVEflag).DataExchangeClient.updateToken(POST /data-exchange/token, 201 →{ token }, Zod-validated) plusbuildDataExchangeUrl/parseDataExchangeCallback/handleDataExchangeCallbackfor the hosted just-in-time grant. Sign-in and data-exchange callbacks now parsegranted_permissionsand seed an optimistic permission cache onYouVersionPlatformConfiguration(grantedPermissions,hasPermission,saveGrantedPermissions,removeGrantedPermission); the cache is cleared on sign-out and a 401/403 invalidates it (server truth wins).useHighlightAuthActionsexposing the one-fell-swoop sign-in (requestinghighlights), the just-in-time data-exchange redirect, the permission-cache reads/invalidation, and the data-exchange return handler.useBibleReaderHighlightsnow runs the state machine — pending highlights persist tosessionStorage(~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_LIVEflag).useBibleReaderHighlightsis now a thin adapter overbibleReaderHighlightsMachine; the machine (authored withsetup()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 indocs/highlight-flow-statechart.md. All previously-shipped invariants are preserved.Behavior changes:
SignInDialog(introducing the app, with an optional integrator prompt) instead of redirecting to OAuth immediately. Confirm launches the sign-in redirect requestinghighlights; decline/dismiss discards the pending highlight and keeps the verse selection. The dialog'sappNamecomes fromYouVersionPlatformConfiguration.appName(falling back to "This app") and its prompt fromsignInPromptMessage. The hook return gainssignInDialogOpen,confirmSignInDialog, andcancelSignInDialog.HIGHLIGHTS_LIVEis off,VerseActionPopoverhides the color row and the remove (checkmark) circles entirely via a newhighlightsEnabledprop — only Copy / Share remain. Previously the row still rendered while taps were inert.Updated dependencies [c85d8de]
Updated dependencies [337ae5c]
Updated dependencies [337ae5c]
@youversion/platform-core@2.4.0
Patch Changes
337ae5c: Fix four highlights-stack bugs surfaced by a staging session, plus a fill fade-in.
defaultbutton variant pairedbg-backgroundwithtext-primary-foreground, resolving to white-on-white in the light theme (the highlight permission dialog's Continue button was invisible). It now uses the standardbg-primary/text-primary-foregroundpairing.YouVersionAuthButtonpinsbg-backgroundexplicitly so its neutral brand surface is unchanged.useHighlights.createHighlight/deleteHighlightno longer refetch on each call. Direct consumers ofuseHighlightsmust now callrefetch()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.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. TheHighlightsClient.deleteHighlightdocstring 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.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
highlightspermission now stashes the intent and runs the two-path grant flow (YPE-1034, still behind the internalHIGHLIGHTS_LIVEflag).DataExchangeClient.updateToken(POST /data-exchange/token, 201 →{ token }, Zod-validated) plusbuildDataExchangeUrl/parseDataExchangeCallback/handleDataExchangeCallbackfor the hosted just-in-time grant. Sign-in and data-exchange callbacks now parsegranted_permissionsand seed an optimistic permission cache onYouVersionPlatformConfiguration(grantedPermissions,hasPermission,saveGrantedPermissions,removeGrantedPermission); the cache is cleared on sign-out and a 401/403 invalidates it (server truth wins).useHighlightAuthActionsexposing the one-fell-swoop sign-in (requestinghighlights), the just-in-time data-exchange redirect, the permission-cache reads/invalidation, and the data-exchange return handler.useBibleReaderHighlightsnow runs the state machine — pending highlights persist tosessionStorage(~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.0to2.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.@youversion/platform-core,@youversion/platform-react-hooks, and@youversion/platform-react-uiall move to2.4.0in lockstep, satisfying the repo's unified-versioning invariant. The minor bump is driven by the breaking behavior change inuseHighlights(refetch coalescing) inplatform-react-hooks; the other two packages follow suit.bible-reader-controlled-mode,bible-reader-highlights-api,fix-highlights-jam-issues,highlight-auth-flow,localization-aria-labels, andxstate-highlights-floware all consumed and removed, which is the expected lifecycle for changeset entries.packages/hooksandpackages/uireference sibling packages viaworkspace:*, 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
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"]Reviews (7): Last reviewed commit: "chore: version packages" | Re-trigger Greptile
Context used: