edfcore 0.4.279 → 0.4.281

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.279";
+export declare const VERSION = "0.4.281";
 //# 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.279';
+export const VERSION = '0.4.281';
 //# sourceMappingURL=constants.js.map

package/docs/CHANGELOG.md

@@ -6,6 +6,34 @@ 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.281
+
+- **Checked** that `sideEffects: false` is honest, rather than merely present. 0.4.230 read the
+  flag out of the manifest; this imports the three entry points in a fresh child realm and watches
+  what happens. A bundler reads that flag and feels free to drop any import whose bindings go
+  unused, so a module that did something at load — patched a global, started a timer, registered a
+  handler — would have licensed the bundler to delete behaviour a consumer depends on, with
+  nothing about the failure pointing back here.
+- A child process because the question is about a fresh realm: by the time any test runs, the
+  parent has imported `src/` a hundred times over. Three things are watched — a new property on
+  `globalThis`, a timer, a `process` listener — which is not exhaustive and is what a load-time
+  side effect looks like in practice, each of them silent from the outside. Verified by adding one
+  of each to the barrel and watching both fail.
+
+## 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

package/package.json

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