edfcore 0.4.525 → 0.4.527

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.4.525";
112
+ export declare const VERSION = "0.4.527";
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.4.525';
82
+ export const VERSION = '0.4.527';
83
83
  //# sourceMappingURL=constants.js.map
package/docs/CHANGELOG.md CHANGED
@@ -6,6 +6,41 @@ 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.4.527
10
+
11
+ - **Fixed** the `0.4.514` heading, which read like a version that shipped. It does not exist on
12
+ npm: the release run bumped, committed and pushed it, CI failed, and no tag was cut — but the
13
+ bump was already public on `main`, which spends the number. A reader comparing
14
+ `npm view edfcore versions` against this file would have found a hole with a normal-looking entry
15
+ over it, which is the exact shape `0.4.307` was written to stop.
16
+ - The entry now opens with the notice, says which kind of never it was, and points forward to
17
+ `0.4.515`, where both CLI tests actually shipped. `0.4.515`'s own entry gains the column work it
18
+ had been carrying without saying so.
19
+ - The cause is worth writing down because it is a process defect rather than a code one. The
20
+ commit contained a test file for the NEXT version, still half-finished in the working tree, which
21
+ `git add -A` swept in — the same way `0.4.474` acquired a mutated source file mid-experiment.
22
+ Nothing in the repository can catch that; the only thing that does is not leaving unfinished work
23
+ in the tree while a release is in flight.
24
+
25
+ ## 0.4.526
26
+
27
+ - **Added** the callout on `diagnostics.md` that stops a reader gating a read on the wrong number:
28
+ "`report.ok` is `severity !== 'error'` over a superset of `header.diagnostics`". It says three
29
+ things, each a claim about behaviour, and `diagnostic-docs.test.ts` checked only that the page
30
+ still words it that way.
31
+ - The superset half is the one that could rot in silence. `validateRecording` builds its own list,
32
+ so a header diagnostic dropped on the way in leaves the report describing a cleaner file than the
33
+ header did — and the report is the stricter of the two by construction, which is the direction
34
+ nobody thinks to check. Every diagnostic is now matched by severity, code and message, so two
35
+ occurrences of one code are two entries rather than one.
36
+ - `ok` is asserted as the sentence the page writes it as, twice over: directly against the report's
37
+ own diagnostics, and through `summarizeDiagnostics(...).errors === 0`, which is what a caller
38
+ actually counts with.
39
+ - The last clause is checked on the file it is about. A signal with a degenerate digital range
40
+ carries an `error`-severity diagnostic and makes `report.ok` false — and the file reads perfectly,
41
+ including that channel's samples, which is the deferred-fatal contract and the entire reason the
42
+ callout exists. Both verdicts are reached across the eight shapes, so neither is a constant.
43
+
9
44
  ## 0.4.525
10
45
 
11
46
  - **Added** a check that what the CLI prints is what the library reports, over the eight awkward
@@ -239,26 +274,22 @@ defect; those are called out below.
239
274
  the test, so a flag that gains or loses a command in the prose changes what is checked. The
240
275
  paragraph needs splitting at each flag to read: only two of the three carry a parenthesised list,
241
276
  and one pattern across the whole paragraph reads the third one's list as the second one's.
277
+ - It carries `0.4.514`'s work as well, because that release never happened: the six columns of
278
+ `edfcore signals` are checked by content rather than by count, against the order read out of the
279
+ page's own table. Until 0.2.42 the page described a column list the command did not emit —
280
+ samples per record where it printed `kind`, and the authoritative field in no column at all — and
281
+ a count of six would not have caught that. `sampleRateHz` is empty on a legal zero record
282
+ duration, where `undefined`, `0` and `NaN` would each be a number a script divides by; `label`
283
+ and `physicalDimension` are trimmed by different things, and removing either now fails.
242
284
 
243
285
  ## 0.4.514
244
286
 
245
- - **Added** a check of what is in the six columns `edfcore signals` prints. `cli.md` tabulates them
246
- by name and position and ends the sixth row with the instruction the command exists for — "the
247
- authoritative count; index by this, never by the rate" — and the only test was that there are six
248
- columns and one line per signal, which six columns of anything satisfy.
249
- - That is the defect the page records against itself. Until 0.2.42 it described a column list the
250
- command did not emit: samples per record where the command printed `kind`, and the authoritative
251
- field in no column at all. A count of six would not have caught it then either. The order is now
252
- read out of the page's table rather than written in the test, so the two cannot drift apart.
253
- - The fixture gives its two data signals different sample counts and different units, so 4 Hz, 1.5
254
- Hz, 8 and 3 are all distinct — no pair of columns can be swapped and still match.
255
- - The three qualified rows are checked as qualified. `sampleRateHz` is empty on a legal zero record
256
- duration, where `undefined`, `0` and `NaN` would each be a number a script divides by. `label`
257
- and `physicalDimension` are both called trimmed, and are trimmed by different things: the parser
258
- strips EDF padding from both, the command adds `String.trim` to the dimension — which reaches a
259
- tab — and passes the label through `printable`, which turns a tab into `.`. Removing either
260
- fails now; before this, removing the first put a tab in the dimension and removing the second put
261
- a seventh column in the row, handing `cut -f6` a unit where it expected a sample count.
287
+ Never released. The release run bumped the version, committed and pushed before `npm run check`
288
+ reached CI, and CI then failed on a test file the commit should not have contained: the flag-matrix
289
+ test written for the NEXT version was still half-finished in the working tree, and `git add -A`
290
+ swept it in. No tag was cut and nothing reached npm, but the bump was already public on `main`,
291
+ which is what spent the number. Both CLI tests — the six columns of `signals` and the flag matrix —
292
+ shipped in `0.4.515`, with the flag parser fixed.
262
293
 
263
294
  ## 0.4.513
264
295
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "edfcore",
3
- "version": "0.4.525",
3
+ "version": "0.4.527",
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.4.525';
96
+ export const VERSION = '0.4.527';