edfcore 0.4.299 → 0.4.300

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.
@@ -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.299";
112
+ export declare const VERSION = "0.4.300";
113
113
  //# sourceMappingURL=constants.d.ts.map
package/dist/constants.js CHANGED
@@ -79,5 +79,5 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
79
79
  reserved: 224,
80
80
  };
81
81
  /** Published package version. Kept in sync with package.json by a test. */
82
- export const VERSION = '0.4.299';
82
+ export const VERSION = '0.4.300';
83
83
  //# sourceMappingURL=constants.js.map
package/docs/CHANGELOG.md CHANGED
@@ -6,6 +6,23 @@ 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.300
10
+
11
+ - **Executed** the claim the error API is shaped around. `src/errors.ts` says class identity is
12
+ false across a realm boundary, `api-errors.md` repeats it, and `public-api.test.ts` files
13
+ `isEdfError` under a heading calling it the cross-realm discriminator — none of them showed it
14
+ happening. An API built entirely around a property nobody demonstrated is an API built around a
15
+ belief.
16
+ - Two copies of the module rather than a `vm` realm, because two copies is the case that reaches
17
+ people: one dependency tree resolving edfcore twice, which npm does whenever two packages want
18
+ incompatible ranges. `instanceof` fails across them, `isEdfError` does not, and the
19
+ discriminator survives — while `instanceof` keeps working inside one copy, which is what makes
20
+ the failure invisible to every test a consumer writes against their own.
21
+ - Writing it corrected my reading of `isEdfError`: it is a duck type, and a plain object with a
22
+ string `edfErrorKind` passes. That is the design rather than a hole — tightening it to
23
+ `instanceof Error` would reintroduce the problem, since `Error` identity is per-realm too, so
24
+ the check would fail on exactly the foreign errors it exists to recognise. The test says so.
25
+
9
26
  ## 0.4.299
10
27
 
11
28
  - **Extended** `verify:site` to check the generated markdown carries the page, not just its head.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "edfcore",
3
- "version": "0.4.299",
3
+ "version": "0.4.300",
4
4
  "description": "Modern, typed, zero-dependency reader for EDF, EDF+, BDF and BDF+ biosignal files. Works in browsers and Node with true random access.",
5
5
  "keywords": [
6
6
  "edf",
package/src/constants.ts CHANGED
@@ -93,4 +93,4 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
93
93
  } as const;
94
94
 
95
95
  /** Published package version. Kept in sync with package.json by a test. */
96
- export const VERSION = '0.4.299';
96
+ export const VERSION = '0.4.300';