@estiva-app/interop 0.1.0 → 0.1.2

package/CHANGELOG.md

@@ -6,7 +6,51 @@ how a declaration is read, is a MAJOR — in `0.x`, a MINOR — even when no
 TypeScript signature moved. A consumer upgrading must be able to tell whether
 manifests already published still mean what they meant.
 
-## 0.1.0 — unreleased
+## 0.1.2 — 2026-08-31
+
+**Manifest behaviour: unchanged.** A build fix; 0.1.1 was tagged and never
+published, so this is the first release carrying its peer-range change.
+
+- **`prebuild` builds `@estiva-app/protocol` first.** This package resolves that
+  one's *types* through its `dist/`, which does not exist in a fresh checkout
+  until it has been built — so `npm run build -w packages/interop`, which is
+  exactly what the release workflow runs, failed with four TS2307s that read as
+  if this package were broken.
+
+  **It is the first foundation package that depends on another one.** protocol,
+  identity and hello have no workspace siblings, so every release before this
+  was independent and the workflow never had to care.
+
+  Building every package instead would not have fixed it: `npm run build
+  --workspaces` runs alphabetically, and `interop` sorts before `protocol`.
+  Measured rather than assumed — that was the first fix attempted and it failed
+  the same way. The dependency belongs in the package that has it.
+
+## 0.1.1 — 2026-08-31 (tagged, never published)
+
+**Manifest behaviour: unchanged.** No resolution, declaration or export moved.
+
+- **`peerDependencies` relaxed to `@estiva-app/protocol >=0.1.2`**, from
+  `>=0.2.0`.
+
+  The stricter range was not justified by anything this package uses. It was
+  chosen because the foundation repo happened to sit at 0.2.0 when the package
+  was written — a fact about the workspace, not about the dependency.
+
+  Found the way these things are found: **the second consumer tried to install
+  it.** Peek is on `protocol@0.1.2` and `npm install` refused with `ERESOLVE`,
+  which would have forced an unrelated protocol upgrade to adopt this package.
+  Verified rather than assumed before relaxing — all four symbols this package
+  imports (`encodeNaddr`, `pointerToAddress`, `referenceToPointer`,
+  `parseProfile`) are exported by 0.1.2, and 0.2.0's change was to `Relay`'s
+  paging, which this package does not use because it takes a `QueryFn` instead
+  of a client.
+
+  This is SHA-7's lesson one level up. The package shipped with one consumer
+  that happened to be on the newer protocol, so nothing exercised the floor of
+  the range until somebody else installed it.
+
+## 0.1.0 — 2026-08-31
 
 First publish. Extracted from `peek-app/interop/`, which was extracted from
 `peek-app/convex/nostr/projection.ts` (PRO-1) — a path that said Convex about a

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@estiva-app/interop",
-  "version": "0.1.0",
+  "version": "0.1.2",
   "description": "Render and act on another app's objects from its published NIP-89 manifest. The owner defines the projection; the consumer decides how it looks.",
   "license": "MIT",
   "type": "module",
@@ -40,13 +40,14 @@
     "estiva"
   ],
   "scripts": {
+    "prebuild": "npm run build --workspace @estiva-app/protocol",
     "build": "tsc -p tsconfig.json",
     "test": "npm run build && node --test test/*.test.mjs",
     "typecheck": "npm run build && tsc -p tsconfig.json --noEmit false --emitDeclarationOnly",
     "prepublishOnly": "npm run build"
   },
   "peerDependencies": {
-    "@estiva-app/protocol": ">=0.2.0"
+    "@estiva-app/protocol": ">=0.1.2"
   },
   "devDependencies": {
     "@estiva-app/protocol": "^0.2.0",