edfcore 0.5.18 → 0.5.19

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -109,5 +109,5 @@ export declare const SIGNAL_FIELD_BLOCK_OFFSETS: {
109
109
  readonly reserved: 224;
110
110
  };
111
111
  /** Published package version. Kept in sync with package.json by a test. */
112
- export declare const VERSION = "0.5.18";
112
+ export declare const VERSION = "0.5.19";
113
113
  //# sourceMappingURL=constants.d.ts.map
package/dist/constants.js CHANGED
@@ -79,5 +79,5 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
79
79
  reserved: 224,
80
80
  };
81
81
  /** Published package version. Kept in sync with package.json by a test. */
82
- export const VERSION = '0.5.18';
82
+ export const VERSION = '0.5.19';
83
83
  //# sourceMappingURL=constants.js.map
package/docs/CHANGELOG.md CHANGED
@@ -6,6 +6,28 @@ alone does not tell you whether you were affected.
6
6
  edfcore is pre-1.0. Patch releases have carried behaviour changes where the old behaviour was a
7
7
  defect; those are called out below.
8
8
 
9
+ ## 0.5.19
10
+
11
+ - **Added** the table on `diagnostics.md` that says which calls take `strict`. Eleven functions in
12
+ two columns, and nothing read it. `strict-decision.test.ts` covers what `strict` does — the info
13
+ exemption, the four always-fatal conditions — and `strict-reaches.test.ts` how far into a file it
14
+ reaches. Which entry points accept it at all was prose.
15
+ - It is the kind of table that goes stale silently, in both directions. A function that grows a
16
+ `ParseOptions` parameter joins the left column without anyone editing the page, and a caller
17
+ reading the right column concludes it cannot be made strict. A function whose options type is
18
+ narrowed leaves the left column the same way, and a caller passing `strict` to it gets one that is
19
+ quietly ignored — an option that type-checks, runs, and does nothing.
20
+ - The two columns are checked by different means, because they are different claims. The six on the
21
+ left are **driven**: each is given a file with a real non-`info` defect — a non-standard reserved
22
+ field for the header three, a malformed TAL for the annotation three — and each must throw
23
+ `EdfFormatError` carrying that code under `strict: true` and collect the same diagnostic without
24
+ it. That is the only way to catch a `strict` that is accepted and dropped.
25
+ - The five on the right are checked **structurally**, out of `src/`: each function's options
26
+ parameter is resolved to its declared type, the `extends` and `&` chain is followed, and `strict`
27
+ must not be reachable through it. A behavioural check cannot prove that negative — passing an
28
+ option a signature does not declare is a compile error, not a runtime one. The same resolver is
29
+ then pointed at the left column, which is what keeps the two halves honest.
30
+
9
31
  ## 0.5.18
10
32
 
11
33
  - **Added** the unscalable signal `diagnostics.md` walks through, run from the throw to the read.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "edfcore",
3
- "version": "0.5.18",
3
+ "version": "0.5.19",
4
4
  "description": "Modern, typed, zero-dependency reader for EDF, EDF+, BDF and BDF+ biosignal files. Works in browsers and Node with true random access.",
5
5
  "keywords": [
6
6
  "edf",
package/src/constants.ts CHANGED
@@ -93,4 +93,4 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
93
93
  } as const;
94
94
 
95
95
  /** Published package version. Kept in sync with package.json by a test. */
96
- export const VERSION = '0.5.18';
96
+ export const VERSION = '0.5.19';