edfcore 0.4.375 → 0.4.377

package/dist/constants.d.ts

@@ -109,5 +109,5 @@ export declare const SIGNAL_FIELD_BLOCK_OFFSETS: {
     readonly reserved: 224;
 };
 /** Published package version. Kept in sync with package.json by a test. */
-export declare const VERSION = "0.4.375";
+export declare const VERSION = "0.4.377";
 //# sourceMappingURL=constants.d.ts.map

package/dist/constants.js

@@ -79,5 +79,5 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
     reserved: 224,
 };
 /** Published package version. Kept in sync with package.json by a test. */
-export const VERSION = '0.4.375';
+export const VERSION = '0.4.377';
 //# sourceMappingURL=constants.js.map

package/docs/CHANGELOG.md

@@ -6,6 +6,36 @@ alone does not tell you whether you were affected.
 edfcore is pre-1.0. Patch releases have carried behaviour changes where the old behaviour was a
 defect; those are called out below.
 
+## 0.4.377
+
+- **Added** a check that the exports badge and the API-surface table on the README show the same
+  number, and a check on the reason they can. `/api.json` sums the runtime exports of the three
+  published entry points at build time; `api-surface.test.ts` counts the same thing from the
+  barrels and asserts the table. Two counters, one number, printed a screen apart on the same page.
+- They agree because the three entry points share no runtime name, so a sum is the same as a union
+  — and nothing stated that. Re-exporting `openEdf` from `edfcore/node` so a Node consumer needs
+  one import is an obvious convenience, and it would make the badge count it twice: 79 above a
+  table reading 78, on the page a reader is looking at to decide whether to install the package.
+  Neither number would be wrong about what it measures, which is what makes the disagreement hard
+  to explain and easy to ship.
+
+## 0.4.376
+
+- **Fixed** a gap in `.gitignore`: `.venv/` was not in it. `scripts/golden/README.md` tells you to
+  build a virtualenv at the repository root and install pyedflib and mne into it, and
+  `scripts/release.mjs` stages with `git add -A` — whose docblock says that `-A` honours
+  `.gitignore`, "which is what keeps `dist/`, `node_modules/` and `tests/scratch/` out". A
+  regeneration run followed by a release would have put a few hundred megabytes of Python into a
+  release commit, by following two sets of documented instructions in order.
+- **Added** the check that found it, over the rest of what that README promises. The regeneration
+  block has to name four scripts that exist and every script in the directory, so none is
+  undocumented and none is named that is not there. "The venv is not committed and CI never builds
+  it" is checked both ways: the ignore rule, and no workflow step that installs or runs Python.
+- And the claim the whole harness rests on — "Nothing in `tests/corpus/golden/` is produced by
+  edfcore" — is read off the files rather than trusted. Every golden carries a `producer`, and no
+  producer names this package: a golden regenerated with edfcore's own writer would compare edfcore
+  against itself and pass no matter what either did.
+
 ## 0.4.375
 
 - **Added** `tests/property/read-agreement.test.ts`: the two ways to read the same records return

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "edfcore",
-  "version": "0.4.375",
+  "version": "0.4.377",
   "description": "Modern, typed, zero-dependency reader for EDF, EDF+, BDF and BDF+ biosignal files. Works in browsers and Node with true random access.",
   "keywords": [
     "edf",

package/src/constants.ts

@@ -93,4 +93,4 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
 } as const;
 
 /** Published package version. Kept in sync with package.json by a test. */
-export const VERSION = '0.4.375';
+export const VERSION = '0.4.377';