edfcore 0.6.76 → 0.6.78

package/dist/constants.d.ts

@@ -109,5 +109,5 @@ export declare const SIGNAL_FIELD_BLOCK_OFFSETS: {
     readonly reserved: 224;
 };
 /** Published package version. Kept in sync with package.json by a test. */
-export declare const VERSION = "0.6.76";
+export declare const VERSION = "0.6.78";
 //# sourceMappingURL=constants.d.ts.map

package/dist/constants.js

@@ -79,5 +79,5 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
     reserved: 224,
 };
 /** Published package version. Kept in sync with package.json by a test. */
-export const VERSION = '0.6.76';
+export const VERSION = '0.6.78';
 //# sourceMappingURL=constants.js.map

package/docs/CHANGELOG.md

@@ -6,6 +6,39 @@ alone does not tell you whether you were affected.
 edfcore is pre-1.0. Patch releases have carried behaviour changes where the old behaviour was a
 defect; those are called out below.
 
+## 0.6.78
+
+- **Fixed** the first code sample on the landing page, which did not compile. It ended
+  `chunk.signals[0].digital` — two `TS2532`s under `noUncheckedIndexedAccess`, on in this repo and
+  in every strict project. That is the same line, broken the same way, that 0.4.259 fixed in
+  `AGENTS.md` after that file "taught a line the compiler rejects".
+- It is the code most people who ever see edfcore will read, and nothing compiled it.
+  `doc-snippets-compile.test.ts` sweeps every FENCED block on the site that imports from
+  `edfcore`; a template literal inside `index.astro` is not one, so the page's samples sat outside
+  a sweep that would have caught this the day it was written.
+- The page's stance is unchanged — recipes belong on a docs page, and this one shows shape. A
+  shape the compiler rejects is the wrong shape. The sample now has a twin in
+  `tests/types/landing-snippet.test-d.ts` that `npm run typecheck` compiles, and a test reads the
+  sample back out of the page and asserts the two have not drifted, which is the pair
+  `agents-snippet.test-d.ts` already uses.
+
+  The twin lives in `tests/types/`, where `agents-snippet.test-d.ts` keeps its own drift check
+  beside the compiled code rather than in a separate file — a `.test-d.ts` with no `it` in it is a
+  suite vitest fails on, which the first run of this release found.
+
+## 0.6.77
+
+- **Fixed** the `EdfAnnotation` example on `api-types.md`, which listed `onsetTicks` with the
+  comment "compare with this" and did not list `onsetTicksFromFirstRecord` at all.
+- The table four lines below it says the opposite — the rebased field is "the axis `readWindow`,
+  `readEnvelope` and `segment.startTicks` use" — and `types.ts` calls `onsetTicks` the wrong one
+  for comparing an annotation against a window. This is the defect 0.6.56 fixed in
+  `tal/annotations.ts`, in the place a reader copies from rather than the place they read.
+- The example compounded it: both fields print `15000000n` there, because that file declares no
+  sub-second start offset. That is most files, and exactly why an example is the worst place to
+  learn which field to use. A note now says so, and the test builds a file with an offset and
+  shows the two differing by it.
+
 ## 0.6.76
 
 - **Fixed** the inspector placing each sample at `part.startSeconds + i / rate`, over a rate it

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "edfcore",
-  "version": "0.6.76",
+  "version": "0.6.78",
   "description": "Modern, typed, zero-dependency reader for EDF, EDF+, BDF and BDF+ biosignal files. Works in browsers and Node with true random access.",
   "keywords": [
     "edf",

package/src/constants.ts

@@ -93,4 +93,4 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
 } as const;
 
 /** Published package version. Kept in sync with package.json by a test. */
-export const VERSION = '0.6.76';
+export const VERSION = '0.6.78';