edfcore 0.4.369 → 0.4.371

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.4.369";
+export declare const VERSION = "0.4.371";
 //# 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.4.369';
+export const VERSION = '0.4.371';
 //# sourceMappingURL=constants.js.map

package/docs/CHANGELOG.md

@@ -6,6 +6,37 @@ 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.4.371
+
+- **Added** a check on where the type tests are actually verified. `tests/types/` holds five
+  `.test-d.ts` files carrying the only assertions a runtime test cannot make — what each subpath
+  can name alone, that the documented examples typecheck, that a `Blob` and a `Response` satisfy
+  the structural shims — and vitest runs them with its own typecheck disabled.
+- That combination reports a false green. Put a plain type error into one and vitest loads it,
+  finds the runtime half fine, and prints a pass; only `npm run typecheck` catches it, because
+  `tsconfig.json` happens to include `tests`. Nothing connected that line to the five files
+  depending on it, and narrowing the include to `src` would look like an ordinary tidy-up: `npm run
+  check` would stay green, vitest would keep reporting the type tests as passing, and every
+  type-level guarantee in the package would be unchecked.
+- So the wiring is asserted rather than assumed — which config the typecheck script names, that its
+  include reaches every type test, that the only exclusion is the gitignored scratch directory, and
+  that vitest is deliberately not the thing doing the checking.
+
+## 0.4.370
+
+- **Added** an execution of the annotations-signal section of `concepts.md`, the page the README
+  calls the mental model the rest of the API follows from. Both claims in it describe a wrong
+  answer that looks right.
+- Decoding an annotations channel as samples yields "a plausible-looking trace made of ASCII" with
+  no wobble to say anything went wrong, so the refusal is the feature and the page prints the whole
+  message — now compared word for word. It is a plain `RangeError` rather than an `EdfError`
+  because it can only be a caller's mistake, which is checked from the consumer's side: a handler
+  branching on `isEdfError` must not catch it, or a caller's bug gets reported as a bad file.
+- The second is that only the first annotations signal carries timekeeping, so only its first TAL
+  is stripped. Stripping the others deletes a real event silently — the annotation is simply not in
+  the list and nothing says one is missing — so a file with two annotation channels now has to
+  return both of their first events.
+
 ## 0.4.369
 
 - **Added** a check over what a `ValidationReport` promises on `validation.md`. `ok` is the field a

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "edfcore",
-  "version": "0.4.369",
+  "version": "0.4.371",
   "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.4.369';
+export const VERSION = '0.4.371';