edfcore 0.3.61 → 0.3.63

package/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.3.63
+
+- **Fixed** `diagnostics.md`'s always-fatal table, which said "Nine codes are always fatal", listed
+  **eight**, and then said "All eight throw `EdfFormatError`".
+  - The missing row was `RECORDING_SPAN_UNREPRESENTABLE` — `recordCount × recordDuration` beyond the
+    signed 64-bit tick range, so the later records have no representable start. It is in
+    `api-errors.md`'s own always-fatal table, so the package's two diagnostic pages disagreed about
+    how many always-fatal codes there are.
+- The 0.3.39 guard checked the prose count on this page and the tables on `api-errors.md`, but not
+  this page's table — which is why the count and the rows under it could drift apart. It now
+  requires every `fatal` code in `codes.ts` to have a row here, requires every row to actually be
+  fatal, and requires the "All N throw" sentence to spell the number the source has.
+
+## 0.3.62
+
+- **Fixed** the Start-here page teaching `strict` with the one code family `strict` cannot fire on,
+  and printing that code's severity wrong.
+  - `concepts.md` showed `await openEdf(source, { strict: true })` producing
+    `EdfFormatError: [DATE_CLIPPED_TO_1985_2084]`. That never happens. `info` codes are exempt from
+    `strict` — `collector.ts` gates on `this.strict && diagnostic.severity !== 'info'` and says why
+    in the same docblock — and `DATE_CLIPPED_TO_1985_2084` is `info`. Run against a file whose only
+    defect is that code, `strict: true` resolves.
+  - Ten lines above, the same page printed `// warning DATE_CLIPPED_TO_1985_2084 168` as the output
+    of `console.log(diagnostic.severity, ...)`. The real first field is `info`.
+  - The `strict` example now uses `PATIENT_ID_NONCONFORMANT`, which is a warning and does throw, and
+    the page says out loud that `info` is exempt and why: nearly every EDF file carries this code,
+    so making `strict` throw on it would mean rejecting conforming files.
+- The 0.3.39 guard could not see this. It matched `severity [CODE]` — the shape `formatDiagnostics`
+  emits — and this page prints the `console.log(severity, code, byteOffset)` shape instead. It now
+  checks both, so a page cannot state a severity the package would not print in either form.
+
 ## 0.3.61
 
 - **Fixed** `inspectEdf` reporting a complete, perfectly readable file as `SOURCE_TOO_SMALL`, at

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

package/package.json

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