fix(cloudflare): respect explicit cache.enabled: false in wrangler config

[astrobot-houston]

Summary

Fixes a bug where cloudflareConfigCustomizer would silently override an explicit cache: { enabled: false } in the user's wrangler config when cacheCloudflare() was configured as a cache provider.

Root Cause

In packages/integrations/cloudflare/src/wrangler.ts, the cache auto-enable condition used a falsy check:

// Before
cache: needsWorkerCache && !config.cache?.enabled ? { enabled: true } : undefined,

!config.cache?.enabled evaluates to true for both:

• config.cache is undefined — cache not configured at all (correct: should auto-enable)
• config.cache.enabled is false — user explicitly opted out (incorrect: should be respected)

Fix

Changed to a strict === undefined check so auto-enabling only applies when the user hasn't set the cache field at all:

// After
cache: needsWorkerCache && config.cache?.enabled === undefined ? { enabled: true } : undefined,

An explicit cache: { enabled: false } is now preserved through the build. This is consistent with how other fields in the same function (main, compatibility_date, assets) handle their defaults using nullish coalescing.

Why this matters

Workers Cache supports per-entrypoint enablement via the exports block. A valid pattern is to leave the top-level enabled: false while enabling cache on specific named entrypoints — e.g., an uncached gateway entry that routes into a cached worker export. Previously the only workaround was post-processing dist/server/wrangler.json after the build.

Testing

Four new unit tests added under a worker cache describe block in packages/integrations/cloudflare/test/wrangler.test.ts:

1. Auto-enables cache when needsWorkerCache: true and cache is unconfigured
2. Does not enable cache when needsWorkerCache: false
3. Does not override when cache is already enabled: true
4. Does not override explicit cache.enabled: false (regression test for this issue)

Confirmed working by issue reporter @skezo against the preview build.

Closes #17375

[changeset-bot]

⚠️ No Changeset found

Latest commit: 474b589

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.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

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