edfcore 0.4.277 → 0.4.279
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 +31 -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.279";
|
|
113
113
|
//# sourceMappingURL=constants.d.ts.map
|
package/dist/constants.js
CHANGED
package/docs/CHANGELOG.md
CHANGED
|
@@ -6,6 +6,37 @@ 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.279
|
|
10
|
+
|
|
11
|
+
- **Added** a check on which Node built-ins the package imports, read from the README's own
|
|
12
|
+
sentence: "Zero runtime dependencies, permanently. `edfcore/node` imports `node:fs/promises` and
|
|
13
|
+
nothing else." Every built-in in the graph is something a bundler has to shim, a serverless
|
|
14
|
+
runtime has to provide and an Electron or Deno target has to allow — one is a footnote, three is
|
|
15
|
+
a compatibility matrix. The neighbouring claims were checked and this one was not:
|
|
16
|
+
`public-api.test.ts` proves the universal entry reaches no `node:` at all and
|
|
17
|
+
`readme-status.test.ts` proves exactly two modules import one, but neither says which, so adding
|
|
18
|
+
`node:path` to the Node adapters would have left both green and the README wrong.
|
|
19
|
+
- Comments are stripped and string literals deliberately are not, which is the reverse of what
|
|
20
|
+
0.4.275 and 0.4.277 needed. An import specifier is a string literal, so the shared `codeOnly`
|
|
21
|
+
removes the thing being counted — the first version of this file used it and reported every
|
|
22
|
+
module as importing nothing. The match is anchored to an import statement instead, so a built-in
|
|
23
|
+
named inside a diagnostic message is not mistaken for a dependency.
|
|
24
|
+
|
|
25
|
+
## 0.4.278
|
|
26
|
+
|
|
27
|
+
- **Corrected** a sentence in `tests/README.md` that contradicted the rest of the page and the
|
|
28
|
+
repository. It opened with "No file anyone else wrote is in this repository", and the six
|
|
29
|
+
committed binaries under `corpus/golden/` were written by pyEDFlib's own `EdfWriter` —
|
|
30
|
+
`scripts/golden/README.md` says so in its second line, "nothing in `tests/corpus/golden/` is
|
|
31
|
+
produced by edfcore", and `AGENTS.md` explains they exist "because the parity harness has to
|
|
32
|
+
compare against bytes another implementation wrote". The page's own later section is headed
|
|
33
|
+
"Checking against files we did not write".
|
|
34
|
+
- The true claim is narrower and worth stating properly: nobody else's *recording* is committed —
|
|
35
|
+
the downloaded corpus is gitignored under `tests/corpus/files/` — and those six were generated
|
|
36
|
+
locally from data this repository specifies. That another implementation wrote them is not an
|
|
37
|
+
exception to the policy, it is the entire reason they are kept: regenerating them with
|
|
38
|
+
`support/writer.ts` would make the comparison circular and prove nothing.
|
|
39
|
+
|
|
9
40
|
## 0.4.277
|
|
10
41
|
|
|
11
42
|
- **Fixed** a test budget that has now been wrong twice, by making it a different kind of number.
|
package/package.json
CHANGED
package/src/constants.ts
CHANGED