edfcore 0.4.373 → 0.4.375
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 +33 -0
- 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.375";
|
|
113
113
|
//# sourceMappingURL=constants.d.ts.map
|
package/dist/constants.js
CHANGED
package/docs/CHANGELOG.md
CHANGED
|
@@ -6,6 +6,39 @@ 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.375
|
|
10
|
+
|
|
11
|
+
- **Added** `tests/property/read-agreement.test.ts`: the two ways to read the same records return
|
|
12
|
+
the same samples. `readWindow` resolves a time window and splits it; `readRecords` is handed a
|
|
13
|
+
range directly. Every worked example in the documentation uses whichever is more convenient, so a
|
|
14
|
+
caller who computes a range with `resolveTimeWindow` and reads it with `readRecords` has to get
|
|
15
|
+
exactly what `readWindow` would have returned — and nothing said so.
|
|
16
|
+
- Each has thorough tests of its own and they share a decoder, but the layer above the decoder is
|
|
17
|
+
separate, and a divergence there is not a decode bug: the samples would be individually correct
|
|
18
|
+
and attached to the wrong records, which is the failure mode this package treats as the worst
|
|
19
|
+
kind because nothing about the numbers looks wrong.
|
|
20
|
+
- So the fixture's generator makes every sample a function of its own record and position, and the
|
|
21
|
+
second property checks each returned value against where the chunk says it came from — over
|
|
22
|
+
arbitrary geometries, since the interesting windows are the awkward ones: shorter than a record,
|
|
23
|
+
starting mid-record, running off the end.
|
|
24
|
+
|
|
25
|
+
## 0.4.374
|
|
26
|
+
|
|
27
|
+
- **Added** a check over what `installation.md` says each entry point contains. The page names
|
|
28
|
+
roughly twenty functions across three paragraphs as the answer to "what do I get if I import
|
|
29
|
+
this", and a name in that list that is not an export sends a reader to an import error on their
|
|
30
|
+
first line. It is also checked to name nothing that lives behind `edfcore/node`, which is the
|
|
31
|
+
claim the whole browser story rests on.
|
|
32
|
+
- The exports map is printed as JSON — not a description of `package.json` but `package.json`,
|
|
33
|
+
retyped, which is the strongest form of a copy and the easiest to let drift. `publint` and
|
|
34
|
+
`packaging-claims.test.ts` check the real map for shape and for the absence of environment
|
|
35
|
+
conditions; neither can see that the page prints the same three entries. It is now parsed and
|
|
36
|
+
compared entry for entry, and the six condition names the page lists are checked against the
|
|
37
|
+
manifest.
|
|
38
|
+
- "Two functions" for `edfcore/node` is asserted as an exact count rather than a floor: that entry
|
|
39
|
+
point exists to be the only module a browser build must not reach, so every name added to it is
|
|
40
|
+
another thing a bundler has to be kept away from.
|
|
41
|
+
|
|
9
42
|
## 0.4.373
|
|
10
43
|
|
|
11
44
|
- **Added** a cross-check between the two tables of the four onset fields — `annotations.md` lists
|
package/package.json
CHANGED
package/src/constants.ts
CHANGED