@astrojs/cloudflare@13.0.0-alpha.1
Breaking Changes📦 astroView on GitHub →
⚠ 3 breaking✨ 2 features🔧 6 symbols
Summary
This release introduces a major update to the Cloudflare adapter, moving the development server to the workerd runtime and simplifying the custom entrypoint API. It also adds support for the 'astro preview' command and refactors how Cloudflare-specific properties are accessed in Astro.locals.
⚠️ Breaking Changes
- The custom entrypoint API has changed: the createExports() function is replaced by a direct export pattern. The manifest is now handled internally by the adapter.
- Astro.locals.runtime has been replaced by Astro.locals.cfContext. Properties like env, cf, and caches have been removed from this object.
- The development server (astro dev) now runs in the Cloudflare workerd runtime instead of Node.js, which may change behavior to match production more closely.
Migration Steps
- In custom entrypoint files, remove createExports() and use a direct 'export default' for the handler.
- Update imports for Cloudflare environment variables: use 'import { env } from "cloudflare:workers"' instead of Astro.locals.runtime.env.
- Access Cloudflare properties (cf) directly from the request: use 'Astro.request.cf' instead of Astro.locals.runtime.cf.
- Use the global 'caches' object directly instead of Astro.locals.runtime.caches.
- Replace references to 'Astro.locals.runtime' with 'Astro.locals.cfContext' to access the Cloudflare ExecutionContext.
✨ New Features
- Added support for the 'astro preview' command, allowing local testing of Cloudflare Workers using the workerd runtime.
- Development server now uses Cloudflare's workerd runtime, enabling local support for Durable Objects, Workers Analytics Engine, and R2 bindings.
🔧 Affected Symbols
createExportsAstro.locals.runtimeAstro.locals.cfContextAstro.request.cf@astrojs/cloudflare/handler@astrojs/cloudflare/utils/handler