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.
- package/dist/constants.d.ts +1 -1
- package/dist/constants.js +1 -1
- package/docs/CHANGELOG.md +48 -17
- package/package.json +1 -1
- package/src/constants.ts +1 -1
package/dist/constants.d.ts
CHANGED
|
@@ -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.
|
|
112
|
+
export declare const VERSION = "0.4.527";
|
|
113
113
|
//# sourceMappingURL=constants.d.ts.map
|
package/dist/constants.js
CHANGED
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
|
-
|
|
246
|
-
|
|
247
|
-
|
|
248
|
-
|
|
249
|
-
|
|
250
|
-
|
|
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
package/src/constants.ts
CHANGED