@blamejs/blamejs-shop 0.0.110 → 0.0.111

package/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.0.x
 
+- v0.0.111 (2026-05-23) — **Restore /feed.xml + /sitemap.xml — `b.safeUrl.parse` returns a URL instance, not a string.** `/feed.xml` and `/sitemap.xml` have been responding 503 "temporarily unavailable" since they shipped. Root cause: three edge handlers (sitemap, feed, scheduled cache-warmer) chained `.replace(/\/$/, "")` directly off `b.safeUrl.parse(...)`. The framework primitive returns a WHATWG `URL` instance, not a string — `URL.prototype.replace` doesn't exist, so every request threw `TypeError: ... .replace is not a function`. The handler's catch swallowed the throw and returned the canonical 503, making the routes appear transiently unavailable when they were in fact permanently broken on that callsite. The bug went undetected because production deploys were frozen at v0.0.101 for a separate reason (now fixed in v0.0.110), so the broken handlers never reached live traffic until today. Fix: chain `.href.replace(/\/$/, "")` so the string method operates on the URL's href string. A new `safeurl-parse-string-method` detector catches the shape repo-wide (47 detectors → adds 1, total 47 → 48). **Added:** *`safeurl-parse-string-method` codebase-patterns detector* — Flags `b.safeUrl.parse(...).<strMethod>(` anywhere under `worker/` — covers `replace` / `startsWith` / `endsWith` / `split` / `includes` / `slice` / `indexOf` / `toLowerCase` / `toUpperCase`. Property access (`.href`) is intentionally NOT flagged — that's the correct shape. The detector exists because three handlers shipped this anti-pattern without anyone noticing while production was frozen; pre-merge detection prevents the next instance from regressing through review the same way. **Fixed:** *Restore `/feed.xml`, `/sitemap.xml`, and the scheduled cache-warmer* — Three callsites in `worker/index.js` shipped `b.safeUrl.parse(env.D1_BRIDGE_URL || "https://blamejs.shop").replace(/\/$/, "")` — `URL.prototype.replace` doesn't exist, so the worker threw TypeError on every request and the edge handler's catch returned the canonical 503. Replaced with `.href.replace(...)` so the trailing-slash strip runs against the URL's serialized form. The semantic contract (operator-configured origin with no trailing slash) is preserved across operator inputs with or without a path prefix.
+
 - v0.0.110 (2026-05-23) — **Unblock Cloudflare production deploys + vendor blamejs v0.12.11 + vendor-drift demoted to warning.** Production Cloudflare Workers deploys have been failing on every push since v0.0.102. Root cause: the container image excludes `worker/` via `.dockerignore` (the worker is deployed separately by `wrangler deploy`, the container only ships the long-running backend), but `test/smoke.js` runs inside the container build's `RUN node test/smoke.js` step and calls the `worker-syntax` gate, which tries to read `worker/index.js` and crashes with `ENOENT`. The Docker build exits 1, `wrangler deploy` aborts, and the production worker is left frozen at the last successful build. The fix: `scripts/check-worker-syntax.js` now skips with a no-op stderr message and exits 0 when its entry file isn't present in the current build context — outside the container (host smoke / CI / npm-publish) the entry is always present and the strict scan runs unchanged. Vendor refresh: blamejs v0.12.11 (carries upstream's matching disciplines). Vendor-drift gate demoted from failure to warning: drift surfaces on stderr (still visible in CI logs + operator terminal) but no longer blocks `npm test` — the committed vendor tree is the source of truth, and operators don't need to refresh on every blamejs release before they can ship an unrelated patch. **Changed:** *`vendor-update.sh --check` warns instead of failing on drift* — Drift between vendored blamejs and the latest upstream tag now surfaces on stderr as `[vendor-check] WARNING — vendored vA.B.C, latest vX.Y.Z` and exits 0. The committed vendor tree is the source of truth — there's no integrity loss from an older-but-still-supported vendor version, and forcing a refresh on every minor blamejs release before any unrelated patch could ship was friction without a corresponding safety win. CI logs and the operator's terminal still display the warning prominently. · *Vendor refresh: blamejs v0.12.10 → v0.12.11* — Standard shallow-clone refresh via `scripts/vendor-update.sh blamejs v0.12.11`. No code changes outside `lib/vendor/blamejs/`. **Fixed:** *Worker-syntax gate skips gracefully when `worker/index.js` is absent* — `scripts/check-worker-syntax.js` now checks for the existence of its entry file before scanning. When the file is missing (Cloudflare container build context, where `worker/` is excluded by `.dockerignore`), the gate logs `[worker-syntax] SKIPPED — <entry> not present in this build context (no worker tree to scan)` to stderr and exits 0. When the file IS present (host smoke runs, CI runners, npm-publish workflow, edge-render checks) the strict balance-walker scan runs unchanged and a missing trailing `}` still fails the build. Unblocks production deploys that have been failing since v0.0.102.
 
 - v0.0.109 (2026-05-23) — **Blog-table-resilient D1 queries + tighter `edge-handler-catch-returns-null` regex.** Live probing surfaced that `/feed.xml` (503), `/sitemap.xml` (503), and `/blog` (500) all fail when the live D1 doesn't have the `blog_articles` table — migration `0189` ships with the blogArticles primitive (v0.0.75) but hadn't been applied to the live deployment yet. The four blog-touching queries in `worker/data/catalog.js` now treat `"no such table"` errors as "no published articles" and return empty rows, so the dependent edge routes degrade gracefully (feed renders no items, sitemap renders only the product + static URLs, /blog shows the empty-state). The `edge-handler-catch-returns-null` detector also tightens — the previous regex spanned 400 chars after the catch's opening `{`, which reached across function boundaries into the next function's guard-clause `return null;` and tripped a false positive. The new regex uses `[^}]` to stay inside the catch body. **Fixed:** *Blog-table-resilient queries in `worker/data/catalog.js`* — `listPublishedBlogSlugs`, `listBlogArticles`, `getBlogArticleBySlug`, and `recentBlogArticles` now catch `"no such table"` errors from D1 and return empty rows / null. Operators who haven't applied migration `0189_blog_articles.sql` (or who deploy the worker before the migrations land) get a clean degradation instead of `/feed.xml` 503 / `/sitemap.xml` 503 / `/blog` 500. Non-table-missing errors still propagate to the caller's `_edgeError` for the canonical 5xx render. · *`edge-handler-catch-returns-null` regex tightened — no more cross-function false positives* — Previous regex: `catch\s*\(\s*[\w$]+\s*\)\s*\{[\s\S]{0,400}?return\s+null\s*;` — the `[\s\S]` matches anything including the catch's closing `}`, so a small catch body followed shortly by a function-guard `return null;` was matching as if the null were inside the catch. New regex: `catch\s*\(\s*[\w$]+\s*\)\s*\{[^}]{0,400}return\s+null\s*;` — `[^}]` keeps the match inside the catch body. Catches still flagged for injection-tested anti-pattern (`catch (e) { return null; }`); the blog-query data layer's guard-clause `return null` outside any catch is no longer flagged. · *Blog-query refactor — null-return moves outside the catch body* — `getBlogArticleBySlug` now uses a `var row = null` outer binding and assigns inside the try; the catch swallows the missing-table case without an inner `return null`. The function's contract ("returns the row or null when not found") is preserved; the tightened detector regex doesn't flag the new shape.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/blamejs-shop",
-  "version": "0.0.110",
+  "version": "0.0.111",
   "description": "Open-source framework built on blamejs. Vendored stack, zero npm runtime deps, PQC-first crypto, security-on by default.",
   "main": "lib/index.js",
   "scripts": {