Support Waku in autoconfig

[dario-piotrowicz]

Fixes https://jira.cfdata.org/browse/DEVX-2328

---

• Tests
  • Tests included/updated
  • Tests not necessary because:
• Public documentation
  • Cloudflare docs PR(s):
  • Documentation not necessary because: tracked elsewhere
• Wrangler V3 Backport
  • Wrangler PR:
  • Not necessary because: autoconfig is not in v3

A picture of a cute animal (not mandatory, but encouraged)

[changeset-bot]

🦋 Changeset detected

Latest commit: bc67f8d

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

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

[claude]

Claude finished @dario-piotrowicz's task —— View job

---

Changeset Review

⚠️ Issues found

Both changeset files are missing required descriptions and need improvement:

.changeset/chilly-camels-serve.md (create-cloudflare)

Issues:

• Missing body/description: The changeset only contains a title. According to the guidelines, it should include:
  1. A single sentence title (✅ present: "Support Waku in --experimental mode")
  2. One or more paragraphs explaining the change (❌ missing)
  3. For new features (minor), a brief usage example (❌ missing)

Suggested format:

---
"create-cloudflare": minor
---

Support Waku in `--experimental` mode

You can now create a new Waku project using create-cloudflare with the `--experimental` flag:

` ` `bash
pnpm create cloudflare --experimental --framework waku my-waku-app
` ` `

This adds Waku to the list of supported frameworks for creating Cloudflare Workers projects.

.changeset/tall-jobs-taste.md (wrangler)

Issues:

• Missing body/description: The changeset only contains a title. According to the guidelines, it should include:
  1. A single sentence title (✅ present: "Support Waku in autoconfig")
  2. One or more paragraphs explaining the change (❌ missing)
  3. For new features (minor), a brief usage example (❌ missing)

Suggested format:

---
"wrangler": minor
---

Support Waku in autoconfig

Waku projects are now automatically detected and configured when using `wrangler dev` and `wrangler deploy`. The autoconfig system will automatically set up the appropriate configuration for Waku's SSR output.

This enables seamless deployment of Waku applications to Cloudflare Workers without manual configuration.

Validation Summary

• ✅ Version Types: Both use minor which is correct for new framework support
• ✅ Major Version Check: No forbidden major bumps for wrangler
• ✅ Markdown Headers: No h1/h2/h3 headers present (none used at all)
• ❌ Changelog Quality: Missing explanatory body paragraphs and usage examples

Recommendation: Update both changeset files to include body paragraphs explaining the changes and brief usage examples, following the format shown in the suggestions above.

[pkg-pr-new]

create-cloudflare

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

@cloudflare/kv-asset-handler

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

miniflare

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

@cloudflare/pages-shared

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

@cloudflare/unenv-preset

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

@cloudflare/vite-plugin

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

@cloudflare/vitest-pool-workers

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

@cloudflare/workers-editor-shared

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

@cloudflare/workers-utils

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

wrangler

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

commit: bc67f8d

[ascorbic]

Could this be a breaking change for user projects?

[dario-piotrowicz]

mh... maybe 😕

I could avoid bumping the version, the app seems to keep working fine if I don't do that, but there might be type errors (I've been seeing them during manual testing)

I guess it's a question of which issue we prefer to leave to the user:

• likely types errors in the waku conflict file
• possibility to break their project somehow

(PS: maybe it's not relevant but not that waku is still at 0.x so it's not fully stable I guess?)

what do you think? 🤔

[ascorbic]

I would err towards not doing it, or to checking the version and not running autoconfig if it's too old

[dario-piotrowicz]

I would err towards not doing it

I can skip it, as I mentioned the app still works even though the types issue

or to checking the version and not running autoconfig if it's too old

I'd probably avoid this, as Brendan commented a few times, it's probably better to proceed and get the user farther then possible instead of stopping earlier. Given that this is a very recoverable issue anyways I'd really opt to plunge ahead anyways.

[ascorbic]

I would go with principle of least surprise. I would not expect a platform to upgrade my project's dependencies, particularly when it's a prerelease with breaking changes. Breaking changes could be subtle, and not visible to us in the build