edfcore 0.4.278 → 0.4.280

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.278";
+export declare const VERSION = "0.4.280";
 //# 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.278';
+export const VERSION = '0.4.280';
 //# 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.280
+
+- **Added** a check that the exit-code table on the CLI page is the code the CLI returns.
+  `edfcore validate` exiting non-zero is the documented way to gate a CI job on file conformance,
+  so those three numbers are an interface a script branches on without parsing a word of output.
+  The page stated them and `cli.test.ts` asserted them against literals it holds itself — two
+  statements of one contract, kept in step by hand, which is the shape 0.4.267 found in the
+  `signals` column table.
+- Each code is produced through both halves of the CLI, because `runCli` returns 0 and 2 and never
+  1: an unreadable file throws, and `src/cli.ts` is what turns that into `error instanceof
+  CliUsageError ? 2 : 1`. A check that drove only `runCli` would have quietly never exercised the
+  row a CI gate depends on most. The row for 2 is also read for the four cases it lists — unknown
+  command, missing file, extra files, bad flag value — and all four are produced.
+
+## 0.4.279
+
+- **Added** a check on which Node built-ins the package imports, read from the README's own
+  sentence: "Zero runtime dependencies, permanently. `edfcore/node` imports `node:fs/promises` and
+  nothing else." Every built-in in the graph is something a bundler has to shim, a serverless
+  runtime has to provide and an Electron or Deno target has to allow — one is a footnote, three is
+  a compatibility matrix. The neighbouring claims were checked and this one was not:
+  `public-api.test.ts` proves the universal entry reaches no `node:` at all and
+  `readme-status.test.ts` proves exactly two modules import one, but neither says which, so adding
+  `node:path` to the Node adapters would have left both green and the README wrong.
+- Comments are stripped and string literals deliberately are not, which is the reverse of what
+  0.4.275 and 0.4.277 needed. An import specifier is a string literal, so the shared `codeOnly`
+  removes the thing being counted — the first version of this file used it and reported every
+  module as importing nothing. The match is anchored to an import statement instead, so a built-in
+  named inside a diagnostic message is not mistaken for a dependency.
+
 ## 0.4.278
 
 - **Corrected** a sentence in `tests/README.md` that contradicted the rest of the page and the

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "edfcore",
-  "version": "0.4.278",
+  "version": "0.4.280",
   "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.278';
+export const VERSION = '0.4.280';