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.
- package/dist/constants.d.ts +1 -1
- package/dist/constants.js +1 -1
- package/docs/CHANGELOG.md +22 -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.5.
|
|
112
|
+
export declare const VERSION = "0.5.19";
|
|
113
113
|
//# sourceMappingURL=constants.d.ts.map
|
package/dist/constants.js
CHANGED
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
package/src/constants.ts
CHANGED