feat(wrangler): send detected framework as annotation during deploy

[ericclemmons]

Summary

When autoconfig detects a framework during wrangler deploy, include it as a workers/framework annotation in the deploy metadata sent to EWC.

Why

The Pages Convergence dashboard needs to cross-reference framework with deploy type (static vs dynamic) for Workers. Currently:

• Wrangler's autoconfig already detects the framework (Next.js, Astro, Nuxt, SvelteKit, etc.) — this is GA since Feb 2026
• But it only sends the framework to Sparrow telemetry (autoconfig_detection_completed), NOT to EWC
• EWC's workerdeploy Ready Analytics event has no framework field

What

• Thread detectedFramework (from getDetailsForAutoConfig()) through to deploy()
• Include it as "workers/framework" in the annotations record (same pattern as workers/message and workers/tag)
• 2 files changed, 9 insertions, 1 deletion

Companion changes

• EWC (Draft MR !9152): Read workers/framework from annotations and emit as blob9 in the workerdeploy RA event
• Jira: BANDA-1799

Impact

Deploy path	Framework sent?
wrangler deploy (auto-config detects framework)	Yes — via workers/framework annotation
wrangler deploy (existing wrangler.toml, no autoconfig)	No — detectedFramework is undefined, annotation omitted
Workers CI build → wrangler deploy	Yes — CI uses wrangler internally, autoconfig runs
Dashboard / API deploy	No — no wrangler involved

Supported frameworks (from autoconfig)

Next.js, Astro, Nuxt, TanStack Start, SolidStart, React Router, SvelteKit, Docusaurus, Qwik, Analog, Hono, Vite, Vike, Waku, Hydrogen, + "static" for static-only sites

[changeset-bot]

⚠️ No Changeset found

Latest commit: ddce78a

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[ask-bonk]

Now I have full context to evaluate the PR. Let me summarize my findings:

The change is straightforward and correct:

1. Threads detectedFramework from autoconfig through to the deploy function
2. Includes it as "workers/framework" in annotations, following the same pattern as workers/message and workers/tag
3. Type-safe: CfWorkerInit.annotations already accepts Record<string, string | undefined>
4. JSON.stringify strips undefined values, so only defined annotation keys are sent over the wire
5. Existing tests won't break because they pass a script argument which disables autoconfig

There is one thing worth noting but it's not a bug: the changeset bot flagged this PR has no changeset. Per the repo's AGENTS.md: "Every change to package code requires a changeset or it will not trigger a release." This is a minor change (new feature). However, commenting on missing changesets is a process note, not a code logic issue, and the bot already flagged it.

I don't see any logic bugs, security issues, backward compatibility violations, or incorrect API behavior. The code follows existing patterns correctly.

LGTM

github run

[pkg-pr-new]

create-cloudflare

npm i https://pkg.pr.new/create-cloudflare@13743

@cloudflare/kv-asset-handler

npm i https://pkg.pr.new/@cloudflare/kv-asset-handler@13743

miniflare

npm i https://pkg.pr.new/miniflare@13743

@cloudflare/pages-shared

npm i https://pkg.pr.new/@cloudflare/pages-shared@13743

@cloudflare/unenv-preset

npm i https://pkg.pr.new/@cloudflare/unenv-preset@13743

@cloudflare/vite-plugin

npm i https://pkg.pr.new/@cloudflare/vite-plugin@13743

@cloudflare/vitest-pool-workers

npm i https://pkg.pr.new/@cloudflare/vitest-pool-workers@13743

@cloudflare/workers-editor-shared

npm i https://pkg.pr.new/@cloudflare/workers-editor-shared@13743

@cloudflare/workers-utils

npm i https://pkg.pr.new/@cloudflare/workers-utils@13743

wrangler

npm i https://pkg.pr.new/wrangler@13743

commit: ddce78a

[ericclemmons]

This is the gotcha – auto-config doesn't always run.

The thinking is being able to leverage the same inference for auto-config to ensure successful zero-config support long-term for any recognized framework.

(Example: auto-config may not support Vite+ today, but if detected but not instrumented, this data would move it up in priority)