diff --git a/.changeset/aligned-versions.md b/.changeset/aligned-versions.md deleted file mode 100644 index a6655aa3..00000000 --- a/.changeset/aligned-versions.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -"@kingstinct/react-native-healthkit": major -"@react-native-healthkit/core": major -"@react-native-healthkit/health-records": major ---- - -chore: release the three packages on a single, shared version from now on - -`@kingstinct/react-native-healthkit`, `@react-native-healthkit/core` and -`@react-native-healthkit/health-records` compile into one another's binary -through the `ReactNativeHealthkitCore` pod, and nothing in CocoaPods or npm -could previously detect a mismatched combination: the packages declared the -core pod without a version and the core package with an open-ended range, so an -incompatible pair failed as a Swift compile error deep inside `Pods`. - -They are now a changesets `fixed` group: every release publishes all three at -the same version, and the lock is enforced at both levels. - -On npm, `@react-native-healthkit/core` moved from a peer dependency with an -open-ended range to a **regular dependency pinned to an exact version**. Your -package manager now installs the one matching core for you, there is no version -for you to keep in sync, and an incompatible combination cannot be resolved in -the first place. Expo autolinks it through that dependency, so most apps no -longer need to mention core at all; a bare React Native app still lists it, -because the React Native CLI only autolinks packages named in the app's own -`package.json`. - -In CocoaPods, each dependent podspec requires a core pod of exactly its own -version, so anything that slips past npm, such as a mixed-version family with -the main package at 16.0.0 beside health records at 16.1.0, fails at `pod -install` with a version conflict naming both pods rather than as a Swift -compile error or a runtime surprise. - -An exact *peer* range was the obvious alternative and is the one thing that does -not work here: changesets treats a peer dependency leaving its range as breaking -for its dependents, and the fixed group then lifts everyone to that type, so any -minor anywhere in the family would come out as a major. A regular dependency has -no such feedback loop. - -Because the group adopts the highest version in it, this release moves -`@react-native-healthkit/core` and `@react-native-healthkit/health-records` up -to the main package's number. The jump is a renumbering, not a redesign: apart -from the changes described in the other entries of this release, the two -packages are what they were at 0.0.1 and 0.1.0. Upgrade the packages you use -together; mixing majors across the family is no longer supported. diff --git a/.changeset/anchor-and-background-fixes.md b/.changeset/anchor-and-background-fixes.md deleted file mode 100644 index 9a7c4d8e..00000000 --- a/.changeset/anchor-and-background-fixes.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -"@kingstinct/react-native-healthkit": major -"@react-native-healthkit/core": major -"@react-native-healthkit/health-records": major ---- - -fix: reject undecodable anchors instead of silently restarting the query - -`deserializeHKQueryAnchor` now throws for a base64 string that is not a valid -`HKQueryAnchor` archive, in both packages. Previously `@kingstinct/react-native-healthkit` -returned nil for such a value, and the anchored query then ran unanchored and -resolved with the entire data set plus a fresh anchor, so a caller syncing on -the anchor re-ingested everything as new with no error to notice. Pass a -`nil`/absent anchor to start from the beginning deliberately; anything that -fails to decode is now an error. - -Also in this release: - -- The core pod's background-delivery manager is registered under the - Objective-C name `RNHealthKitCoreBackgroundDeliveryManager` rather than the - bare `BackgroundDeliveryManager` that `@kingstinct/react-native-healthkit` 15 - and earlier export. Installing a core-based `@react-native-healthkit/health-records` - alongside such a version no longer puts two classes with one name in the - binary, which could leave the launch hook resolving either of them and - silently drop background delivery. -- Metadata values of a type that cannot cross the bridge are still dropped, but - the warning is now logged once per metadata key per process instead of once - per sample, so it surfaces without flooding the console or the - background-delivery window. -- `@react-native-healthkit/core` no longer ships an ESM build. Its previous - `import` entry could not actually be loaded by Node: the main entry used - extensionless directory imports and the plugin entry took named imports from - CommonJS `@expo/config-plugins`. The `import` condition now resolves to the - CommonJS build, which Node imports with working named exports. diff --git a/.changeset/core-package.md b/.changeset/core-package.md deleted file mode 100644 index a056fb48..00000000 --- a/.changeset/core-package.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -"@react-native-healthkit/core": major ---- - -feat: add `@react-native-healthkit/core`, the shared foundation of `@kingstinct/react-native-healthkit` and `@react-native-healthkit/health-records`: the TypeScript types both packages expose, the non-iOS stub helper, the Expo config plugin building blocks, and the `ReactNativeHealthkitCore` pod with the shared `HKHealthStore`, query, anchor, predicate and metadata helpers, Objective-C exception catching and the launch-time background-delivery observer registration diff --git a/.changeset/health-records-on-core.md b/.changeset/health-records-on-core.md deleted file mode 100644 index c6d87656..00000000 --- a/.changeset/health-records-on-core.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -"@react-native-healthkit/health-records": major ---- - -refactor: move the code shared with `@kingstinct/react-native-healthkit` into the new `@react-native-healthkit/core` dependency. - -Nothing to install: core is pinned to this package's exact version, so your package manager brings in the matching copy and Expo autolinks it. Bare React Native apps must still list it in their own `package.json` (`bun add @react-native-healthkit/core`), because the React Native CLI only autolinks packages named there. The public API is unchanged, and background delivery configured before this release keeps working: the shared manager reads the existing UserDefaults keys. diff --git a/.changeset/healthkit-on-core.md b/.changeset/healthkit-on-core.md deleted file mode 100644 index 8c10d678..00000000 --- a/.changeset/healthkit-on-core.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -"@kingstinct/react-native-healthkit": major ---- - -refactor: move the code shared with `@react-native-healthkit/health-records` into the new `@react-native-healthkit/core` package. - -Nothing to install: core is a regular dependency pinned to this package's exact version, so your package manager brings in the matching copy and Expo autolinks it. Bare React Native apps must still list it in their own `package.json`, because the React Native CLI only autolinks packages named there: - -```sh -bun add @react-native-healthkit/core -``` - -Public API is unchanged. The shared types (`AuthorizationStatus`, `UpdateFrequency`, `Device`, `SourceRevision`, `DateFilter`, `EmitterSubscription`, …) are still exported from this package but are now the same declarations as in `@react-native-healthkit/health-records`, so values can flow between the two packages without casts. `SampleType` fields and `EmitterSubscription.remove` (which now reports whether the subscription was still active) follow the core definitions. Background delivery configured before this release is picked up unchanged; the shared manager keeps reading the existing UserDefaults keys. diff --git a/.changeset/mighty-moons-shake.md b/.changeset/mighty-moons-shake.md deleted file mode 100644 index 86e444c5..00000000 --- a/.changeset/mighty-moons-shake.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -'@kingstinct/react-native-healthkit': minor ---- - -Add the iOS 27 quantity type `HKQuantityTypeIdentifierHeartRateVariabilityRMSSD` (ms, discrete/arithmetic, writeable), and expose `getEarliestAuthorizedSampleDates` - a binding for `HKHealthStore.earliestAuthorizedSampleDate(for:)`, which reports the earliest date the app may read samples from for each type the user granted only limited access to. Types without a limited-access lower bound are omitted from the result, and on iOS 26 and below it resolves to an empty object since the concept does not exist there. diff --git a/packages/core/CHANGELOG.md b/packages/core/CHANGELOG.md new file mode 100644 index 00000000..a48755ea --- /dev/null +++ b/packages/core/CHANGELOG.md @@ -0,0 +1,73 @@ +# @react-native-healthkit/core + +## 16.0.0 +### Major Changes + +- 908aec2: chore: release the three packages on a single, shared version from now on + + `@kingstinct/react-native-healthkit`, `@react-native-healthkit/core` and + `@react-native-healthkit/health-records` compile into one another's binary + through the `ReactNativeHealthkitCore` pod, and nothing in CocoaPods or npm + could previously detect a mismatched combination: the packages declared the + core pod without a version and the core package with an open-ended range, so an + incompatible pair failed as a Swift compile error deep inside `Pods`. + + They are now a changesets `fixed` group: every release publishes all three at + the same version, and the lock is enforced at both levels. + + On npm, `@react-native-healthkit/core` moved from a peer dependency with an + open-ended range to a **regular dependency pinned to an exact version**. Your + package manager now installs the one matching core for you, there is no version + for you to keep in sync, and an incompatible combination cannot be resolved in + the first place. Expo autolinks it through that dependency, so most apps no + longer need to mention core at all; a bare React Native app still lists it, + because the React Native CLI only autolinks packages named in the app's own + `package.json`. + + In CocoaPods, each dependent podspec requires a core pod of exactly its own + version, so anything that slips past npm, such as a mixed-version family with + the main package at 16.0.0 beside health records at 16.1.0, fails at `pod + install` with a version conflict naming both pods rather than as a Swift + compile error or a runtime surprise. + + An exact *peer* range was the obvious alternative and is the one thing that does + not work here: changesets treats a peer dependency leaving its range as breaking + for its dependents, and the fixed group then lifts everyone to that type, so any + minor anywhere in the family would come out as a major. A regular dependency has + no such feedback loop. + + Because the group adopts the highest version in it, this release moves + `@react-native-healthkit/core` and `@react-native-healthkit/health-records` up + to the main package's number. The jump is a renumbering, not a redesign: apart + from the changes described in the other entries of this release, the two + packages are what they were at 0.0.1 and 0.1.0. Upgrade the packages you use + together; mixing majors across the family is no longer supported. +- 908aec2: fix: reject undecodable anchors instead of silently restarting the query + + `deserializeHKQueryAnchor` now throws for a base64 string that is not a valid + `HKQueryAnchor` archive, in both packages. Previously `@kingstinct/react-native-healthkit` + returned nil for such a value, and the anchored query then ran unanchored and + resolved with the entire data set plus a fresh anchor, so a caller syncing on + the anchor re-ingested everything as new with no error to notice. Pass a + `nil`/absent anchor to start from the beginning deliberately; anything that + fails to decode is now an error. + + Also in this release: + + - The core pod's background-delivery manager is registered under the + Objective-C name `RNHealthKitCoreBackgroundDeliveryManager` rather than the + bare `BackgroundDeliveryManager` that `@kingstinct/react-native-healthkit` 15 + and earlier export. Installing a core-based `@react-native-healthkit/health-records` + alongside such a version no longer puts two classes with one name in the + binary, which could leave the launch hook resolving either of them and + silently drop background delivery. + - Metadata values of a type that cannot cross the bridge are still dropped, but + the warning is now logged once per metadata key per process instead of once + per sample, so it surfaces without flooding the console or the + background-delivery window. + - `@react-native-healthkit/core` no longer ships an ESM build. Its previous + `import` entry could not actually be loaded by Node: the main entry used + extensionless directory imports and the plugin entry took named imports from + CommonJS `@expo/config-plugins`. The `import` condition now resolves to the + CommonJS build, which Node imports with working named exports. +- 908aec2: feat: add `@react-native-healthkit/core`, the shared foundation of `@kingstinct/react-native-healthkit` and `@react-native-healthkit/health-records`: the TypeScript types both packages expose, the non-iOS stub helper, the Expo config plugin building blocks, and the `ReactNativeHealthkitCore` pod with the shared `HKHealthStore`, query, anchor, predicate and metadata helpers, Objective-C exception catching and the launch-time background-delivery observer registration diff --git a/packages/core/package.json b/packages/core/package.json index a3ff551e..b4505b8e 100644 --- a/packages/core/package.json +++ b/packages/core/package.json @@ -1,6 +1,6 @@ { "name": "@react-native-healthkit/core", - "version": "15.1.0", + "version": "16.0.0", "description": "Shared types, helpers and native code for the react-native-healthkit packages", "main": "lib/commonjs/index.js", "types": "lib/typescript/index.d.ts", diff --git a/packages/health-records/CHANGELOG.md b/packages/health-records/CHANGELOG.md index 56749a7b..b415d812 100644 --- a/packages/health-records/CHANGELOG.md +++ b/packages/health-records/CHANGELOG.md @@ -1,5 +1,86 @@ # @react-native-healthkit/health-records +## 16.0.0 +### Major Changes + +- 908aec2: chore: release the three packages on a single, shared version from now on + + `@kingstinct/react-native-healthkit`, `@react-native-healthkit/core` and + `@react-native-healthkit/health-records` compile into one another's binary + through the `ReactNativeHealthkitCore` pod, and nothing in CocoaPods or npm + could previously detect a mismatched combination: the packages declared the + core pod without a version and the core package with an open-ended range, so an + incompatible pair failed as a Swift compile error deep inside `Pods`. + + They are now a changesets `fixed` group: every release publishes all three at + the same version, and the lock is enforced at both levels. + + On npm, `@react-native-healthkit/core` moved from a peer dependency with an + open-ended range to a **regular dependency pinned to an exact version**. Your + package manager now installs the one matching core for you, there is no version + for you to keep in sync, and an incompatible combination cannot be resolved in + the first place. Expo autolinks it through that dependency, so most apps no + longer need to mention core at all; a bare React Native app still lists it, + because the React Native CLI only autolinks packages named in the app's own + `package.json`. + + In CocoaPods, each dependent podspec requires a core pod of exactly its own + version, so anything that slips past npm, such as a mixed-version family with + the main package at 16.0.0 beside health records at 16.1.0, fails at `pod + install` with a version conflict naming both pods rather than as a Swift + compile error or a runtime surprise. + + An exact *peer* range was the obvious alternative and is the one thing that does + not work here: changesets treats a peer dependency leaving its range as breaking + for its dependents, and the fixed group then lifts everyone to that type, so any + minor anywhere in the family would come out as a major. A regular dependency has + no such feedback loop. + + Because the group adopts the highest version in it, this release moves + `@react-native-healthkit/core` and `@react-native-healthkit/health-records` up + to the main package's number. The jump is a renumbering, not a redesign: apart + from the changes described in the other entries of this release, the two + packages are what they were at 0.0.1 and 0.1.0. Upgrade the packages you use + together; mixing majors across the family is no longer supported. +- 908aec2: fix: reject undecodable anchors instead of silently restarting the query + + `deserializeHKQueryAnchor` now throws for a base64 string that is not a valid + `HKQueryAnchor` archive, in both packages. Previously `@kingstinct/react-native-healthkit` + returned nil for such a value, and the anchored query then ran unanchored and + resolved with the entire data set plus a fresh anchor, so a caller syncing on + the anchor re-ingested everything as new with no error to notice. Pass a + `nil`/absent anchor to start from the beginning deliberately; anything that + fails to decode is now an error. + + Also in this release: + + - The core pod's background-delivery manager is registered under the + Objective-C name `RNHealthKitCoreBackgroundDeliveryManager` rather than the + bare `BackgroundDeliveryManager` that `@kingstinct/react-native-healthkit` 15 + and earlier export. Installing a core-based `@react-native-healthkit/health-records` + alongside such a version no longer puts two classes with one name in the + binary, which could leave the launch hook resolving either of them and + silently drop background delivery. + - Metadata values of a type that cannot cross the bridge are still dropped, but + the warning is now logged once per metadata key per process instead of once + per sample, so it surfaces without flooding the console or the + background-delivery window. + - `@react-native-healthkit/core` no longer ships an ESM build. Its previous + `import` entry could not actually be loaded by Node: the main entry used + extensionless directory imports and the plugin entry took named imports from + CommonJS `@expo/config-plugins`. The `import` condition now resolves to the + CommonJS build, which Node imports with working named exports. +- 908aec2: refactor: move the code shared with `@kingstinct/react-native-healthkit` into the new `@react-native-healthkit/core` dependency. + + Nothing to install: core is pinned to this package's exact version, so your package manager brings in the matching copy and Expo autolinks it. Bare React Native apps must still list it in their own `package.json` (`bun add @react-native-healthkit/core`), because the React Native CLI only autolinks packages named there. The public API is unchanged, and background delivery configured before this release keeps working: the shared manager reads the existing UserDefaults keys. + +### Patch Changes + +- Updated dependencies [908aec2] +- Updated dependencies [908aec2] +- Updated dependencies [908aec2] + - @react-native-healthkit/core@16.0.0 + ## 0.1.0 ### Minor Changes diff --git a/packages/health-records/package.json b/packages/health-records/package.json index 1e35536e..3c3dfd33 100644 --- a/packages/health-records/package.json +++ b/packages/health-records/package.json @@ -1,6 +1,6 @@ { "name": "@react-native-healthkit/health-records", - "version": "15.1.0", + "version": "16.0.0", "description": "React Native bindings for HealthKit clinical health records (FHIR)", "main": "lib/commonjs/index.js", "module": "lib/module/index.js", @@ -98,7 +98,7 @@ "typescript": "~5.9.3" }, "dependencies": { - "@react-native-healthkit/core": "15.1.0" + "@react-native-healthkit/core": "16.0.0" }, "peerDependencies": { "react": ">=19", diff --git a/packages/react-native-healthkit/CHANGELOG.md b/packages/react-native-healthkit/CHANGELOG.md index 34fe5232..66327290 100644 --- a/packages/react-native-healthkit/CHANGELOG.md +++ b/packages/react-native-healthkit/CHANGELOG.md @@ -1,5 +1,96 @@ # @kingstinct/react-native-healthkit +## 16.0.0 +### Major Changes + +- 908aec2: chore: release the three packages on a single, shared version from now on + + `@kingstinct/react-native-healthkit`, `@react-native-healthkit/core` and + `@react-native-healthkit/health-records` compile into one another's binary + through the `ReactNativeHealthkitCore` pod, and nothing in CocoaPods or npm + could previously detect a mismatched combination: the packages declared the + core pod without a version and the core package with an open-ended range, so an + incompatible pair failed as a Swift compile error deep inside `Pods`. + + They are now a changesets `fixed` group: every release publishes all three at + the same version, and the lock is enforced at both levels. + + On npm, `@react-native-healthkit/core` moved from a peer dependency with an + open-ended range to a **regular dependency pinned to an exact version**. Your + package manager now installs the one matching core for you, there is no version + for you to keep in sync, and an incompatible combination cannot be resolved in + the first place. Expo autolinks it through that dependency, so most apps no + longer need to mention core at all; a bare React Native app still lists it, + because the React Native CLI only autolinks packages named in the app's own + `package.json`. + + In CocoaPods, each dependent podspec requires a core pod of exactly its own + version, so anything that slips past npm, such as a mixed-version family with + the main package at 16.0.0 beside health records at 16.1.0, fails at `pod + install` with a version conflict naming both pods rather than as a Swift + compile error or a runtime surprise. + + An exact *peer* range was the obvious alternative and is the one thing that does + not work here: changesets treats a peer dependency leaving its range as breaking + for its dependents, and the fixed group then lifts everyone to that type, so any + minor anywhere in the family would come out as a major. A regular dependency has + no such feedback loop. + + Because the group adopts the highest version in it, this release moves + `@react-native-healthkit/core` and `@react-native-healthkit/health-records` up + to the main package's number. The jump is a renumbering, not a redesign: apart + from the changes described in the other entries of this release, the two + packages are what they were at 0.0.1 and 0.1.0. Upgrade the packages you use + together; mixing majors across the family is no longer supported. +- 908aec2: fix: reject undecodable anchors instead of silently restarting the query + + `deserializeHKQueryAnchor` now throws for a base64 string that is not a valid + `HKQueryAnchor` archive, in both packages. Previously `@kingstinct/react-native-healthkit` + returned nil for such a value, and the anchored query then ran unanchored and + resolved with the entire data set plus a fresh anchor, so a caller syncing on + the anchor re-ingested everything as new with no error to notice. Pass a + `nil`/absent anchor to start from the beginning deliberately; anything that + fails to decode is now an error. + + Also in this release: + + - The core pod's background-delivery manager is registered under the + Objective-C name `RNHealthKitCoreBackgroundDeliveryManager` rather than the + bare `BackgroundDeliveryManager` that `@kingstinct/react-native-healthkit` 15 + and earlier export. Installing a core-based `@react-native-healthkit/health-records` + alongside such a version no longer puts two classes with one name in the + binary, which could leave the launch hook resolving either of them and + silently drop background delivery. + - Metadata values of a type that cannot cross the bridge are still dropped, but + the warning is now logged once per metadata key per process instead of once + per sample, so it surfaces without flooding the console or the + background-delivery window. + - `@react-native-healthkit/core` no longer ships an ESM build. Its previous + `import` entry could not actually be loaded by Node: the main entry used + extensionless directory imports and the plugin entry took named imports from + CommonJS `@expo/config-plugins`. The `import` condition now resolves to the + CommonJS build, which Node imports with working named exports. +- 908aec2: refactor: move the code shared with `@react-native-healthkit/health-records` into the new `@react-native-healthkit/core` package. + + Nothing to install: core is a regular dependency pinned to this package's exact version, so your package manager brings in the matching copy and Expo autolinks it. Bare React Native apps must still list it in their own `package.json`, because the React Native CLI only autolinks packages named there: + + ```sh + bun add @react-native-healthkit/core + ``` + + Public API is unchanged. The shared types (`AuthorizationStatus`, `UpdateFrequency`, `Device`, `SourceRevision`, `DateFilter`, `EmitterSubscription`, …) are still exported from this package but are now the same declarations as in `@react-native-healthkit/health-records`, so values can flow between the two packages without casts. `SampleType` fields and `EmitterSubscription.remove` (which now reports whether the subscription was still active) follow the core definitions. Background delivery configured before this release is picked up unchanged; the shared manager keeps reading the existing UserDefaults keys. + +### Minor Changes + +- 029edee: Add the iOS 27 quantity type `HKQuantityTypeIdentifierHeartRateVariabilityRMSSD` (ms, discrete/arithmetic, writeable), and expose `getEarliestAuthorizedSampleDates` - a binding for `HKHealthStore.earliestAuthorizedSampleDate(for:)`, which reports the earliest date the app may read samples from for each type the user granted only limited access to. Types without a limited-access lower bound are omitted from the result, and on iOS 26 and below it resolves to an empty object since the concept does not exist there. + +### Patch Changes + +- Updated dependencies [908aec2] +- Updated dependencies [908aec2] +- Updated dependencies [908aec2] + - @react-native-healthkit/core@16.0.0 + ## 15.1.0 ### Minor Changes diff --git a/packages/react-native-healthkit/package.json b/packages/react-native-healthkit/package.json index 78a0fa56..91bc4da1 100644 --- a/packages/react-native-healthkit/package.json +++ b/packages/react-native-healthkit/package.json @@ -1,6 +1,6 @@ { "name": "@kingstinct/react-native-healthkit", - "version": "15.1.0", + "version": "16.0.0", "description": "React Native bindings for HealthKit", "main": "lib/commonjs/index.js", "module": "lib/module/index.js", @@ -103,7 +103,7 @@ "typescript": "~5.9.3" }, "dependencies": { - "@react-native-healthkit/core": "15.1.0" + "@react-native-healthkit/core": "16.0.0" }, "peerDependencies": { "react": ">=19",