fix: remove empty preview_image_url so the Deploy to Cloudflare button works

[tombeckenham]

Problem

The README's Deploy to Cloudflare button fails on this repo with:

There was a problem parsing the Wrangler configuration file. Please raise an issue in the Workers SDK repo.

Root cause

It isn't the Wrangler config. The button's template-metadata parser rejects the empty "preview_image_url": "" in package.json's "cloudflare" block, and the dashboard misattributes the failure to wrangler.jsonc. Filed upstream as cloudflare/workers-sdk#14831.

This was isolated by bisection against deploy.workers.cloudflare.com using fresh subdirectory paths of a public fork (the button caches its pass/fail verdict per repo/path for 30+ minutes, ignoring new commits — so each experiment needs a fresh path):

• official containers-template + this repo's full wrangler.jsonc (containers, standard-4, Dockerfile image, custom build, assets, R2, vars) → ✅ passes
• official template + this repo's package.json → ❌ fails
• "cloudflare" block with only preview_image_url removed → ✅ passes; with only icon_urls removed (empty preview_image_url kept) → ❌ fails
• this repo's complete app, wrangler.jsonc untouched, only this line removed → ✅ button reaches the configure/provision step (project name, R2 bucket picker, binding descriptions all render correctly)

Fix

Delete the empty "preview_image_url": "" line (one-line diff). wrangler.jsonc — including instance_type: "standard-4" — needs no changes. The empty "icon_urls": [] is harmless and kept.

To add a real preview image later, set the field to an actual image URL; it's only the empty string that kills the flow.

Note for verifying after merge

Because of the verdict caching above, the button may keep showing the stale error on this repo's URL for a while after merging. Verify via a fresh checkout path (e.g. the repo URL once the cache expires, or immediately via a copy under a new path).

[jrusso1020]

No blockers. Correct, minimal, and the diagnosis holds up. Verified at head da0342a.

Verification

• Diff is exactly the claimed one line, and it sits mid-block between docs_url and icon_urls, so no trailing-comma breakage. package.json still parses; I loaded it and dumped the cloudflare block to confirm.
• preview_image_url appears nowhere else in the repo. icon_urls: [] is kept, as stated.
• Upstream issue is real and matches — cloudflare/workers-sdk#14831, open, filed 2026-07-24, title describes exactly this misattributed-parse-error behavior.
• The bisection logic is sound and complete. The icon_urls-removed control rules out the sibling field, and the final full-app test leaves categories: [] and icon_urls: [] in place while passing, which independently clears both empty collections. Sufficiency and necessity are both covered.
• Single commit on the branch, no ridealong.

One accurate-framing note: the mechanism ("the template-metadata parser rejects the empty string") is inferred from black-box bisection, not read from source. preview_image_url returns zero hits in cloudflare/workers-sdk, consistent with the parser living in the closed-source dashboard rather than the SDK. That doesn't weaken anything here, the empirical case is strong and the fix has no downside, but it's why the upstream issue is the right call.

Suggestion, non-blocking: the assets you need already exist

The cloudflare block exists to render the template listing card, and this repo already has both pieces of art for it, currently unused by that block:

• docs/preview.png — real 2400x1256 PNG, already rendered in README.md:5, and there's a scripts/screenshot.mjs that regenerates it
• docs/icon.svg — committed, while icon_urls sits empty

So rather than only deleting the field, consider a follow-up that points both at their raw URLs:

"preview_image_url": "https://raw.githubusercontent.com/heygen-com/hyperframes-cloudflare-template/main/docs/preview.png",
"icon_urls": ["https://raw.githubusercontent.com/heygen-com/hyperframes-cloudflare-template/main/docs/icon.svg"],

Worth doing separately, not here, and it needs the same fresh-subdirectory-path verification you describe, since a populated value is untested against the button and only the empty string is known-bad.

Cross-PR note

#10 (the TanStack Start rewrite) carries this same deletion in its own package.json hunk, so there's no regression risk whichever lands first. Expect a trivial overlap on that hunk if #10 rebases after this merges.

Ships the button fix at minimum cost. Good writeup on the caching gotcha too, that would have burned someone an hour.

— Rames Jusso