Skip to content
This repository has been archived by the owner on Feb 10, 2025. It is now read-only.

Latest commit

 

History

History
1709 lines (1059 loc) · 121 KB

CHANGELOG.md

File metadata and controls

1709 lines (1059 loc) · 121 KB

@astrojs/cloudflare

12.2.1

Patch Changes

12.2.0

Minor Changes

Patch Changes

12.1.0

Minor Changes

  • #455 1d4e6fc Thanks @meyer! - Adds wrangler.jsonc to the default watched config files. If a config file is specified in platformProxy.configPath, that file location is watched instead of the defaults.

Patch Changes

  • #476 a8a8ab1 Thanks @bluwy! - Removes resolving with "node" conditionto fix Vue imports

12.0.1

Patch Changes

  • #465 70e0054 Thanks @bluwy! - Fixes setting custom workerd and worker conditions for the ssr environment only

12.0.0

Major Changes

  • #367 e02b54a Thanks @alexanderniebuhr! - Removed support for the Squoosh image service. As the underlying library libsquoosh is no longer maintained, and the image service sees very little usage we have decided to remove it from Astro.

    Our recommendation is to use the base Sharp image service, which is more powerful, faster, and more actively maintained.

    - import { squooshImageService } from "astro/config";
import { defineConfig } from "astro/config";

export default defineConfig({
-  image: {
-    service: squooshImageService()
-  }
});

    If you are using this service, and cannot migrate to the base Sharp image service, a third-party extraction of the previous service is available here: https://github.com/Princesseuh/astro-image-service-squoosh

  • #367 e02b54a Thanks @alexanderniebuhr! - Deprecates the functionPerRoute option

    This option is now deprecated, and will be removed entirely in Astro v5.0. We suggest removing this option from your configuration as soon as you are able to:

    import { defineConfig } from 'astro/config';
import vercel from '@astrojs/vercel/serverless';

export default defineConfig({
  // ...
  output: 'server',
  adapter: vercel({
-     functionPerRoute: true,
  }),
});

  • #375 e7881f7 Thanks @Princesseuh! - Updates internal code to works with Astro 5 changes to hybrid rendering. No changes are necessary to your project, apart from using Astro 5

  • #397 776a266 Thanks @Princesseuh! - Welcome to the Astro 5 beta! This release has no changes from the latest alpha of this package, but it does bring us one step closer to the final, stable release.

    Starting from this release, no breaking changes will be introduced unless absolutely necessary.

    To learn how to upgrade, check out the Astro v5.0 upgrade guide in our beta docs site.

  • #451 f248546 Thanks @ematipico! - Updates esbuild dependency to v0.24.0

  • #392 3a49eb7 Thanks @Princesseuh! - Updates internal code for Astro 5 changes. No changes is required to your project, apart from using Astro 5

Patch Changes

12.0.0-beta.1

Major Changes

12.0.0-beta.0

Major Changes

  • #367 e02b54a Thanks @alexanderniebuhr! - Removed support for the Squoosh image service. As the underlying library libsquoosh is no longer maintained, and the image service sees very little usage we have decided to remove it from Astro.

    Our recommendation is to use the base Sharp image service, which is more powerful, faster, and more actively maintained.

    - import { squooshImageService } from "astro/config";
import { defineConfig } from "astro/config";

export default defineConfig({
-  image: {
-    service: squooshImageService()
-  }
});

    If you are using this service, and cannot migrate to the base Sharp image service, a third-party extraction of the previous service is available here: https://github.com/Princesseuh/astro-image-service-squoosh

  • #367 e02b54a Thanks @alexanderniebuhr! - Deprecates the functionPerRoute option

    This option is now deprecated, and will be removed entirely in Astro v5.0. We suggest removing this option from your configuration as soon as you are able to:

    import { defineConfig } from 'astro/config';
import vercel from '@astrojs/vercel/serverless';

export default defineConfig({
  // ...
  output: 'server',
  adapter: vercel({
-     functionPerRoute: true,
  }),
});

  • #375 e7881f7 Thanks @Princesseuh! - Updates internal code to works with Astro 5 changes to hybrid rendering. No changes are necessary to your project, apart from using Astro 5

  • #397 776a266 Thanks @Princesseuh! - Welcome to the Astro 5 beta! This release has no changes from the latest alpha of this package, but it does bring us one step closer to the final, stable release.

    Starting from this release, no breaking changes will be introduced unless absolutely necessary.

    To learn how to upgrade, check out the Astro v5.0 upgrade guide in our beta docs site.

  • #392 3a49eb7 Thanks @Princesseuh! - Updates internal code for Astro 5 changes. No changes is required to your project, apart from using Astro 5

11.2.0

Minor Changes

  • #423 169ac24 Thanks @schummar! - Changes the logic which generates the _routes.json file to improve generation for projects with many static pages, while still making sure all routes work as expected.

Patch Changes

  • #409 d63bed8 Thanks @alexanderniebuhr! - Fixes an issue where cloudflare: scoped imports made the build fail. We externalize all imports with the cloudflare: scope by default now.

11.1.0

Minor Changes

  • #394 44dfa99 Thanks @veitbjarsch! - Added functionality to compare include and exclude rules to reduce the amount of cloudflare rules

11.0.5

Patch Changes

11.0.4

Patch Changes

  • #344 8d7766e Thanks @Fryuni! - Updates a dependency to align the peer dependency version for Astro

11.0.3

Patch Changes

11.0.2

Patch Changes

  • #340 45d0abb Thanks @alexanderniebuhr! - Fixes an issue if environment variables where used inside the middleware and a prerendering occured.

11.0.1

Patch Changes

11.0.0

Major Changes

  • #290 1c4145e Thanks @alexanderniebuhr! - Cloudflare v11

    Upgrades

    Supported Astro versions

    This release drops support for Astro versions <= 4.10.2. The new supported and required Astro versions are >= 4.10.3. This allowed us to remove additional workarounds related to projects with many prerendered pages. This should fix all bundling issues that are not caused by an upstream package.

    What should I do?

    If you still observe an issue, please check current open issues or create a new one in the repository.

    To upgrade an existing project, use the automated @astrojs/upgrade CLI tool. Alternatively, upgrade manually by running the upgrade command from your package manager:

    # Recommended:
npx @astrojs/upgrade

# Manual:
npm install astro@latest
pnpm upgrade astro --latest
yarn upgrade astro --latest

    Changes

    astro:env

    This release adds experimental support for astro:env, which helps to streamline the usage of environment variables for Astro projects. You can read more about it in Astro Docs. IMPORTANT: Cloudflare Bindings are not supported by astro:env, and still should be accessed by using Astro.locals.runtime.env or context.locals.runtime.env. astro:env supports environment variables only.

    What should I do?

    If you observe any issues, please check current open issues or create a new one in the repository.

    To add environment variables to your project, you still need to make sure they are available in three places. You're setup might require different steps to achieve this, so we can't give you a complete step-by-step guide, on how to achieve the requirements, but here are some guidance to get you started:

    • process.env during build in your node process (astro build)
    • wrangler.toml for local development (astro dev)
    • Cloudflare Pages Dashboard for production deployments

    Add "public" environment variables to your wrangler.toml. (If you add pages_build_output_dir = "./dist" to your wrangler.toml, these will be synced to your Cloudflare Pages Dashboard, and you don't have to add them there manually):

    # wrangler.toml
name = "test"

+[vars]
+API_URL = "https://google.de"
+PORT = 4322

# ...

    If you also need "secret" environment variables (e.g. API Keys, etc.), you add them to your .dev.vars file. (These won't be synced automatically, and you need to add them manually as encrypted variables to the Cloudflare Pages Dashboard or use wrangler CLI to push them):

    # .dev.vars
+ API_SECRET=123456789

    With your environment variables added to those two files and synced to the Cloudflare Pages Dashboard, you should be able to use them with astro:env when running astro dev & astro build, but you need to use Cloudflare's Build Pipeline and Cloudflare's GitHub App connection.

    However if you build your project locally or inside a custom GitHub Action and deploy with direct upload to Cloudflare, you need to ensure that the environment variables are also available for your build process. The simplest but not safest is to use your shell, e.g. API_URL=https://google.de PORT=4322 API_SECRET=123456789 astro build. For more complex setups, you should find out the way for your specific setup to provide environment variables to the build process.

    Additionally, you need to define your schema inside your astro.config.mjs file:

    import { defineConfig, envField } from "astro/config"

export default defineConfig({
+  experimental: {
+    env: {
+      schema: {
+        API_URL: envField.string({ context: "client", access: "public", optional: true }),
+        PORT: envField.number({ context: "server", access: "public", default: 4321 }),
+        API_SECRET: envField.string({ context: "server", access: "secret" }),
+      }
+    }
+  }
})

    Finally, you should be able to access your environment variables in your Astro project, according to the Astro Docs, e.g. import { API_URL } from "astro:env/client" or import { PORT, API_SECRET } from "astro:env/server".

    NOTE: If you want to use environment variables in other files that are not .astro or middleware files, you still need to make sure you don't access the variable in a global scope. We recommend wrapping your logic with a function, which you then call from your .astro or middleware files inside the request scope.

    // foo.ts
import { MY_SECRET } from 'astro:env/server';

// DOESN'T WORK
const client = myLib(MY_SECRET);

// WORKS
export const bar = () => {
  const client = myLib(MY_SECRET);
  return client;
};

    watch config files

    This release starts monitoring your wrangler.toml and .dev.vars files for changes and restarting the dev server if you update them.

    What should I do?

    If you observe any issues, please check current open issues or create a new one in the repository.

    BREAKING: imageService

    This release changes the default behavior of imageService. In the past the default behavior was falling back to a noop service, which disabled image optimization for your project, because Cloudflare doesn's support it. The new default is compile, which enables image optimization for prerendered pages during build, but disallows the usage of any astro:assets feature inside of on-demand pages.

    What should I do?

    If you experience issues with the new setting, you can revert back to the old setting by setting imageService to passthrough. Furthermore if you observe any issues, please check current open issues or create a new one in the repository.

    // astro.config.mjs

// ...
adapter: cloudflare({
-  imageService: 'compile',
}),
// ...

    BREAKING: platformProxy

    This release enables platformProxy by default. While most projects shouldn't be affected, this is a breaking change on paper.

    What should I do?

    If you experience issues with the new default, you can deactivate it by setting platformProxy.enabled to false. Furthermore if you observe any issues, please check current open issues or create a new one in the repository.

    // astro.config.mjs

// ...
adapter: cloudflare({
-  platformProxy: {
-    enabled: true,
-  },
}),
// ...

    BREAKING: passThroughOnException

    This release throws an error if you use Cloudflare's passThroughOnException function because, as stated in Cloudflare docs, the function doesn't work with Cloudflare Pages.

    What should I do?

    If you observe any issues, please check current open issues or create a new one in the repository.

    Deprecations

    wasmModuleImports

    This release removes the previous deprecated wasmModuleImports adapter option and replaces it with the cloudflareModules option, which offers flexibility and support for more file types.

    What should I do?

    If you observe any issues, please check current open issues or create a new one in the repository.

    // astro.config.mjs

// ...
adapter: cloudflare({
-  wasmModuleImports: true,
}),
// ...

10.4.2

Patch Changes

10.4.1

Patch Changes

10.4.0

Minor Changes

10.3.0

Minor Changes

10.2.6

Patch Changes

10.2.5

Patch Changes

  • #249 72fc8ac Thanks @adrianlyjak! - Fixes build errors when wasm modules are imported from a file that is shared in both prerendered static pages and server side rendered pages

10.2.4

Patch Changes

10.2.3

Patch Changes

10.2.2

Patch Changes

10.2.1

Patch Changes

  • #238 1927f94 Thanks @alexanderniebuhr! - Fixes astro build which throws an error if it can't clean up dynamic imports for prerendered pages.

10.2.0

Minor Changes

  • #222 8f312da Thanks @Fryuni! - Fixes an issue, where unused code was not removed from the output, which led to issues with large projects with a lot of prerendered pages.

10.1.0

Minor Changes

  • #229 1f4e40b Thanks @FlorianFlatscher! - Adds a new option for the Image service to the Cloudflare adapter. imageService: 'custom' does use the user defined settings, without applying any modification to it. You need to make sure that the configured settings are compatible with Cloudflare's workerd runtime yourself.

10.0.3

Patch Changes

10.0.2

Patch Changes

  • #217 0349bd4 Thanks @alexanderniebuhr! - fixes an issue where the automatic _routes.json generation was not working as expected for some projects, which had a dynamic route as the first segment

  • #217 0349bd4 Thanks @alexanderniebuhr! - fixes an issue where the automatic _routes.json generation was not limited correctly, which had manual extend patterns

10.0.1

Patch Changes

  • #212 c22bb21 Thanks @alexanderniebuhr! - fixes an issue where projects using @astrojs/solid-js were unusable, due to wrong vite config

  • #210 317bd95 Thanks @alexanderniebuhr! - fixes an issue where projects using @astrojs/vue were unusable, due to marking dependencies as external

10.0.0

Major Changes

  • #159 adb8bf2a4caeead9a1a255740c7abe8666a6f852 Thanks @alexanderniebuhr! - Updates and prepares the adapter to be more flexibile, stable and composable for the future. Includes several breaking changes.

    Upgrade Guide

    We are commited to provide a smooth upgrade path for our users. This guide will describe what has changed from v9.x to v10 to help you to migrate your existing projects to the latest version of the adapter. For complete documentation of all v10 configuration settings and usage, please see the current, updated Cloudflare adapter documentation.

    We will provide at least 4 weeks of limited maintanance support for the previous version 9 of the adapter. Please plan to upgrade your project within this time frame, using the instructions below.

    Adapter's mode option & Cloudflare Functions

    The mode option has been removed from the adapter. The adapter now defaults to the previous advanced mode and this is the only official supported option moving forward.

    If you are already using mode: 'advanced' in your astro.config.mjs file, you can safely remove it.

    import cloudflare from '@astrojs/cloudflare';
import { defineConfig } from 'astro/config';

export default defineConfig({
	adapter: cloudflare({
-		mode: 'advanced',
	}),
});

    If you are using mode: 'directory', and don't have any custom Cloudflare functions in the /function folder, you should be able to remove the mode option, without any issues.

    import cloudflare from '@astrojs/cloudflare';
import { defineConfig } from 'astro/config';

export default defineConfig({
	adapter: cloudflare({
-		mode: 'directory',
	}),
});

    If you are using mode: 'directory', and you have custom Cloudflare functions in the /function folder, you will need to manually migrate them to Astro Server Endpoints (API Routes). If you need to access Cloudflare Bindings, you can use ctx.locals. For further reference, please check the Adapters Documentation on Cloudflare Runtime Usage.

    Adapter's functionPerRoute option

    The functionPerRoute option has been removed from the adapter. The adapter now defaults to the previous false value. If you are using functionPerRoute: true in your astro.config.mjs file, you can safely remove it. This change will not break any existing projects, but you will no longer be generating a single function for each route.

    import cloudflare from '@astrojs/cloudflare';
import { defineConfig } from 'astro/config';

export default defineConfig({
	adapter: cloudflare({
-		functionPerRoute: true,
	}),
});

    Local Runtime

    The adapter replaces the runtime options with a new set of platformProxy options to enable local runtime support when using astro dev.

    If you are already using a wrangler.toml file, you can safely replace your existing runtime options with the appropriate platformProxy options.

    import cloudflare from '@astrojs/cloudflare';
import { defineConfig } from 'astro/config';

export default defineConfig({
	adapter: cloudflare({
-		runtime: {
-			mode: 'local',
-			type: 'workers',
-		},
+		platformProxy: {
+			enabled: true,
+		},
	}),
});

    If you define your bindings in the astro.config.mjs file, you need to first migrate your project to use a wrangler.toml configuration file for defining your bindings. You can find more information on how to do this in the Cloudflare docs about wrangler. Then, replace runtime options with the new corresponding platformProxy options as above.

    import cloudflare from '@astrojs/cloudflare';
import { defineConfig } from 'astro/config';

export default defineConfig({
	adapter: cloudflare({
-		runtime: {
-			mode: 'local',
-			type: 'pages',
-			bindings: {
-				// ...
-			},
-		},
+		platformProxy: {
+			enabled: true,
+		},
	}),
});

    If you have typed locals in your ./src/env.d.ts file, you need to run wrangler types in your project and update the file.

    /// <reference types="astro/client" />

- type KVNamespace = import('@cloudflare/workers-types/experimental').KVNamespace;
- type ENV = {
-   SERVER_URL: string;
-   KV_BINDING: KVNamespace;
- };

- type Runtime = import('@astrojs/cloudflare').AdvancedRuntime<ENV>;
+ type Runtime = import('@astrojs/cloudflare').Runtime<Env>;

declare namespace App {
  interface Locals extends Runtime {

      name: string;
      surname: string;
    };
  }
}

    Routes

    The routes.strategy option has been removed as you will no longer have the option to choose a strategy in v10 of this adpater.

    If you are using routes.strategy, you can remove it. You might observe a different dist/_routes.json file, but it should not affect your project's behavior.

    import cloudflare from '@astrojs/cloudflare';
import { defineConfig } from 'astro/config';

export default defineConfig({
	adapter: cloudflare({
-		routes: {
-			strategy: 'include',
-		},
	}),
});

    Additionally the routes.include & routes.exclude options have changed their name and type. If you were previously using them, move these to the new routes.extend property and update their types:

    import cloudflare from '@astrojs/cloudflare';
import { defineConfig } from 'astro/config';

export default defineConfig({
	adapter: cloudflare({
		routes: {
-			include: ['/api/*'],
-			exclude: ['/fonts/*'],
+			extend: {
+				include: [{ pattern: '/api/*' }],
+				exclude: [{ pattern: '/fonts/*' }],
+			},
		},
	}),
});

    process.env

    In the old version of the adapter we used to expose all the environment variables to process.env. This is no longer the case, as it was unsafe. If you need to use environment variables, you need to use either Astro.locals.runtime.env or context.locals.runtime.env. There is no way to access the environment variables directly from process.env or in the global scope.

    If you need to access the environment variables in global scope, you should refactor your code to pass the environment variables as arguments to your function or file.

    If you rely on any third library that uses process.env, please open an issue and we can investigate what the best way to handle this is.

    Node.js APIs compatibility

    The adapter still supports the same Node.js APIs as Cloudflare does, but you need to adapt your vite configuration and enable the Cloudflare nodejs_compat flag.

    import {defineConfig} from "astro/config";
import cloudflare from '@astrojs/cloudflare';

export default defineConfig({
  adapter: cloudflare({}),
  output: 'server',
+  vite: {
+    ssr: {
+      external: ['node:buffer'],
+    },
+  },
})

9.2.1

Patch Changes

9.2.0

Minor Changes

  • #192 256b7024624ab45d5087d774cb4c30b117f1636a Thanks @alexanderniebuhr! - Prepares for major breaking changes to adapter configuration in the upcoming v10 release.

    (Full documentation to help you migrate your project to the upgraded Cloudflare adapter will be provided with the release of v10.0.)

    Deprecates the following adapter configuration options (to be removed entirely in v10):

    • mode: All projects will deploy to Cloudflare pages using advanced mode (the previous default setting). This is no longer a configurable option. Cloudflare Functions will no longer be supported. If you were using mode: 'directory', please migrate to Astro Endpoints.
    • functionPerRoute: Discontinued due to Cloudflare's single execution context approach. You will no longer have the option to compile a separate bundle for each page.
    • routes.strategy: Projects will use the auto-generated _route.json for route management unless you provide your own public/_routes.json. This change aims to eliminate confusion and promote consistency.
    • routes.include: Will be replaced by a new routes.extend.include option to allow you to include additional routes.
    • routes.exclude: Will be replaced by a new routes.extend.exclude option to allow you to exclude additional routes.
    • runtime: Local runtime bindings will be configured in wrangler.toml at the root of your project as described in the adapters documentation. You will no longer configure these directly in the adapter configuration. A new platformProxy setting will be introduced to enable and configure the platformProxy (local runtime) provided by wrangler.

    These changes are part of ongoing efforts to streamline functionality, improve performance, and align with best practices and platform capabilities.

    We strongly recommend upgrading to v10 upon its release. To ensure a smooth migration, we commit to at least 4 weeks of additional maintenance for v9 following the release of v10. During this period, we will actively assist with migration efforts to ensure that all users can transition without major issues.

9.1.0

Minor Changes

9.0.2

Patch Changes

9.0.1

Patch Changes

9.0.0

Major Changes

Patch Changes

8.1.0

Minor Changes

  • #58 ecdb8f5bc21b19cc86e581711a1c360fc723a007 Thanks @alexanderniebuhr! - Adds the option to only run image optimization on images during build-time. Warning: This mode does not work with on-demand (SSR) image optimization.

    import {defineConfig} from "astro/config";
import cloudflare from '@astrojs/cloudflare';

export default defineConfig({
  output: 'server'
  adapter: cloudflare({
+   imageService: 'compile'
  }),
})

8.0.2

Patch Changes

8.0.1

Patch Changes

8.0.0

Major Changes

  • #94 13ddae8 Thanks @alexanderniebuhr! - Removes deprecated option build.split. Use functionPerRoute instead.

  • #94 13ddae8 Thanks @alexanderniebuhr! - Changes the way that bindings are configured for the local runtime using astro dev. This change is developed in cooperation with Cloudflare and aligns Astro more closely to the behavior of Wrangler.

    ⚠️ This is a breaking change for anyone deploying to Cloudflare Pages. You need to update your astro config file to set new the bindings. Follow the updated docs for configuring @astrojs/cloudflare

Patch Changes

7.7.1

Patch Changes

  • #69 473e9fa Thanks @alexanderniebuhr! - Fixes a regression which caused the adapter to falsely generate _routes.json for on-demand rendered 404 pages, which causes unexpected behavior in Cloudflare's SPA routing.

  • #66 5b62509 Thanks @ToxiWoxi! - Fixes a regression which caused the adapter to falsely return an empty 404 response, caused by an upstream change withastro/astro#7754.

7.7.0

Minor Changes

7.6.4

Patch Changes

7.6.3

Patch Changes

7.6.2

Patch Changes

  • #33 78baf24 Thanks @alexanderniebuhr! - Fixes override of a valid astro:assets image service configuration. Now overrides are only applied when the configuration is known to be incompatible with Cloudflare.

7.6.1

Patch Changes

7.6.0

Minor Changes

  • #23 4a03af2 Thanks @alexanderniebuhr! - Adds a new property persistTo which allows setting the directory for local state files when using Cloudflare runtime with astro dev. This is useful when you want to persist state between restarts of the dev server, for example when using KV, D1, R2 to store data.

    Additionally, updates the format of the runtime configuration and adds a warning when the deprecated format is used. The current format is now runtime: { mode: 'off' | 'local', persistTo: string }. See runtime documentation for more information.

7.5.4

Patch Changes

7.5.3

Patch Changes

7.5.2

Patch Changes

7.5.1

Patch Changes

7.5.0

Minor Changes

  • #8655 3dd65bf88 Thanks @alexanderniebuhr! - Introduces support for local KV bindings. Enhances development experience by allowing direct integration with astro dev.

  • #8655 3dd65bf88 Thanks @alexanderniebuhr! - Introduces support for local Durable Objects bindings. Enhances development experience by allowing direct integration with astro dev.

  • #8655 3dd65bf88 Thanks @alexanderniebuhr! - Introduces support for local D1 bindings. Enhances development experience by allowing direct integration with astro dev.

  • #8655 3dd65bf88 Thanks @alexanderniebuhr! - Introduces support for local R2 bindings. Enhances development experience by allowing direct integration with astro dev.

  • #8655 3dd65bf88 Thanks @alexanderniebuhr! - Introduces support for local Caches bindings. Enhances development experience by allowing direct integration with astro dev.

Patch Changes

7.4.0

Minor Changes

Patch Changes

7.3.1

Patch Changes

7.3.0

Minor Changes

  • #8459 2365c1246 Thanks @schummar! - Adds three new config options for _routes.json generation: routes.strategy, routes.include, and routes.exclude.

  • #8542 faeead423 Thanks @adrianlyjak! - Add support for loading wasm modules in the cloudflare adapter

Patch Changes

7.2.0

Minor Changes

  • #8595 5b0b3c9a8 Thanks @alexanderniebuhr! - Add support for the following Node.js Runtime APIs, which are availabe in Cloudflare using the node: syntax.

    • assert
    • AsyncLocalStorage
    • Buffer
    • Diagnostics Channel
    • EventEmitter
    • path
    • process
    • Streams
    • StringDecoder
    • util
    import { Buffer } from 'node:buffer';

Patch Changes

7.1.1

Patch Changes

7.1.0

Minor Changes

Patch Changes

7.0.2

Patch Changes

7.0.1

Patch Changes

7.0.0

Major Changes

  • #8188 d0679a666 Thanks @ematipico! - Remove support for Node 16. The lowest supported version by Astro and all integrations is now v18.14.1. As a reminder, Node 16 will be deprecated on the 11th September 2023.

  • #8179 6011d52d3 Thanks @matthewp! - Astro 3.0 Release Candidate

  • #8188 7511a4980 Thanks @ematipico! - When using an adapter that supports neither Squoosh or Sharp, Astro will now automatically use an image service that does not support processing, but still provides the other benefits of astro:assets such as enforcing alt, no CLS etc to users

  • #8078 2540feedb Thanks @alexanderniebuhr! - The configuration build.split and build.excludeMiddleware are deprecated.

    You can now configure this behavior using functionPerRoute in your Cloudflare integration config:

    import {defineConfig} from "astro/config";
import cloudflare from '@astrojs/cloudflare';

export default defineConfig({
-    build: {
-        split: true
-    },
-    adapter: cloudflare()
+    adapter: cloudflare({
+        mode: 'directory',
+        functionPerRoute: true
+    })
})

Minor Changes

  • #8188 cd2d7e769 Thanks @ematipico! - Introduced the concept of feature map. A feature map is a list of features that are built-in in Astro, and an Adapter can tell Astro if it can support it.

    import { AstroIntegration } from './astro';

function myIntegration(): AstroIntegration {
  return {
    name: 'astro-awesome-list',
    // new feature map
    supportedAstroFeatures: {
      hybridOutput: 'experimental',
      staticOutput: 'stable',
      serverOutput: 'stable',
      assets: {
        supportKind: 'stable',
        isSharpCompatible: false,
        isSquooshCompatible: false,
      },
    },
  };
}

Patch Changes

7.0.0-rc.3

Major Changes

Patch Changes

7.0.0-beta.2

Major Changes

  • #8078 2540feedb Thanks @alexanderniebuhr! - The configuration build.split and build.excludeMiddleware are deprecated.

    You can now configure this behavior using functionPerRoute in your Cloudflare integration config:

    import {defineConfig} from "astro/config";
import cloudflare from '@astrojs/cloudflare';

export default defineConfig({
-    build: {
-        split: true
-    },
-    adapter: cloudflare()
+    adapter: cloudflare({
+        mode: 'directory',
+        functionPerRoute: true
+    })
})

Patch Changes

7.0.0-beta.1

Minor Changes

Patch Changes

7.0.0-beta.0

Major Changes

  • 1eae2e3f7 Thanks @Princesseuh! - Remove support for Node 16. The lowest supported version by Astro and all integrations is now v18.14.1. As a reminder, Node 16 will be deprecated on the 11th September 2023.

  • c022a4217 Thanks @Princesseuh! - When using an adapter that supports neither Squoosh or Sharp, Astro will now automatically use an image service that does not support processing, but still provides the other benefits of astro:assets such as enforcing alt, no CLS etc to users

Minor Changes

  • 9b4f70a62 Thanks @ematipico! - Introduced the concept of feature map. A feature map is a list of features that are built-in in Astro, and an Adapter can tell Astro if it can support it.

    import { AstroIntegration } from './astro';

function myIntegration(): AstroIntegration {
  return {
    name: 'astro-awesome-list',
    // new feature map
    supportedAstroFeatures: {
      hybridOutput: 'experimental',
      staticOutput: 'stable',
      serverOutput: 'stable',
      assets: {
        supportKind: 'stable',
        isSharpCompatible: false,
        isSquooshCompatible: false,
      },
    },
  };
}

Patch Changes

6.8.1

Patch Changes

6.8.0

Minor Changes

  • #7541 ffcfcddb7 Thanks @alexanderniebuhr! - The getRuntime utility has been deprecated and should be updated to the new Astro.locals API.

    - import { getRuntime } from '@astrojs/cloudflare/runtime';
- getRuntime(Astro.request);

+ const runtime = Astro.locals.runtime;

Patch Changes

6.7.0

Minor Changes

Patch Changes

6.6.2

Patch Changes

6.6.1

Patch Changes

6.6.0

Minor Changes

Patch Changes

6.5.1

Patch Changes

6.5.0

Minor Changes

  • #7386 6d8aa4b61 Thanks @beynar! - Expose cf metadata and Cloudflare Worker Cache API through caches in runtime.

Patch Changes

6.4.0

Minor Changes

  • #7067 57f8d14c0 Thanks @matthewp! - Support for experimental redirects

    This adds support for the redirects RFC in the Cloudflare adapter. No changes are necessary, simply use configured redirects and the adapter will update your _redirects file.

Patch Changes

6.3.0

Minor Changes

Patch Changes

6.2.4

Patch Changes

6.2.3

Patch Changes

6.2.2

Patch Changes

6.2.1

Patch Changes

6.2.0

Minor Changes

Patch Changes

6.1.3

Patch Changes

6.1.2

Patch Changes

6.1.1

Patch Changes

6.1.0

Minor Changes

Patch Changes

6.0.0

Major Changes

  • #5707 5eba34fcc Thanks @bluwy! - Remove astro:build:start backwards compatibility code

  • #5806 7572f7402 Thanks @matthewp! - Make astro a peerDependency of integrations

    This marks astro as a peerDependency of several packages that are already getting major version bumps. This is so we can more properly track the dependency between them and what version of Astro they are being used with.

Patch Changes

6.0.0-beta.1

See changes in 6.0.0-beta.1

Major Changes

  • #5806 7572f7402 Thanks @matthewp! - Make astro a peerDependency of integrations

    This marks astro as a peerDependency of several packages that are already getting major version bumps. This is so we can more properly track the dependency between them and what version of Astro they are being used with.

Patch Changes

6.0.0-beta.0

See changes in 6.0.0-beta.0

Major Changes

Patch Changes

5.0.0

Patch Changes

4.1.1

Patch Changes

4.1.0

Minor Changes

  • #5347 743000cc7 Thanks @AirBorne04! - Now building for Cloudflare directory mode takes advantage of the standard asset handling from Cloudflare Pages, and therefore does not call a function script to deliver static assets anymore. Also supports the use of _routes.json, _redirects and _headers files when placed into the public folder.

Patch Changes

4.0.1

Patch Changes

4.0.0

Major Changes

  • #5290 b2b291d29 Thanks @matthewp! - Handle base configuration in adapters

    This allows adapters to correctly handle base configuration. Internally Astro now matches routes when the URL includes the base.

    Adapters now also have access to the removeBase method which will remove the base from a pathname. This is useful to look up files for static assets.

Patch Changes

3.1.2

Patch Changes

3.1.1

Patch Changes

  • #5103 d151d9f3f Thanks @AirBorne04! - enable access to Cloudflare runtime [KV, R2, Durable Objects]
    • access native Cloudflare runtime through import { getRuntime } from "@astrojs/cloudflare/runtime"; now you can call getRuntime(Astro.request) and get access to the runtime environment.

3.1.0

Minor Changes

  • #5056 e55af8a23 Thanks @matthewp! - # New build configuration

    The ability to customize SSR build configuration more granularly is now available in Astro. You can now customize the output folder for server (the server code for SSR), client (your client-side JavaScript and assets), and serverEntry (the name of the entrypoint server module). Here are the defaults:

    import { defineConfig } from 'astro/config';

export default defineConfig({
  output: 'server',
  build: {
    server: './dist/server/',
    client: './dist/client/',
    serverEntry: 'entry.mjs',
  },
});

    These new configuration options are only supported in SSR mode and are ignored when building to SSG (a static site).

    Integration hook change

    The integration hook astro:build:start includes a param buildConfig which includes all of these same options. You can continue to use this param in Astro 1.x, but it is deprecated in favor of the new build.config options. All of the built-in adapters have been updated to the new format. If you have an integration that depends on this param we suggest upgrading to do this instead:

    export default function myIntegration() {
  return {
    name: 'my-integration',
    hooks: {
      'astro:config:setup': ({ updateConfig }) => {
        updateConfig({
          build: {
            server: '...',
          },
        });
      },
    },
  };
}

3.0.0

Major Changes

  • #4888 2dc582ac5 Thanks @AirBorne04! - adjusting the build settings for cloudflare (reverting back to platform browser over neutral) adjusting the ssr settings for solidjs (to build for node)

2.1.0

Minor Changes

  • #4876 d3091f89e Thanks @matthewp! - Adds the Astro.cookies API

    Astro.cookies is a new API for manipulating cookies in Astro components and API routes.

    In Astro components, the new Astro.cookies object is a map-like object that allows you to get, set, delete, and check for a cookie's existence (has):

    ---
type Prefs = {
  darkMode: boolean;
};

Astro.cookies.set<Prefs>(
  'prefs',
  { darkMode: true },
  {
    expires: '1 month',
  }
);

const prefs = Astro.cookies.get<Prefs>('prefs').json();
---

<body data-theme={prefs.darkMode ? 'dark' : 'light'}></body>

    Once you've set a cookie with Astro.cookies it will automatically be included in the outgoing response.

    This API is also available with the same functionality in API routes:

    export function post({ cookies }) {
  cookies.set('loggedIn', false);

  return new Response(null, {
    status: 302,
    headers: {
      Location: '/login',
    },
  });
}

    See the RFC to learn more.

2.0.0

Major Changes

1.0.2

Patch Changes

1.0.1

Patch Changes

1.0.0

Major Changes

0.5.0

Minor Changes

  • #3806 f4c571bdb Thanks @nrgnrg! - add support for compiling functions to a functions directory rather than _worker.js

0.4.0

Minor Changes

Patch Changes

0.3.0

Minor Changes

  • #4015 6fd161d76 Thanks @matthewp! - New output configuration option

    This change introduces a new "output target" configuration option (output). Setting the output target lets you decide the format of your final build, either:

    • "static" (default): A static site. Your final build will be a collection of static assets (HTML, CSS, JS) that you can deploy to any static site host.
    • "server": A dynamic server application. Your final build will be an application that will run in a hosted server environment, generating HTML dynamically for different requests.

    If output is omitted from your config, the default value "static" will be used.

    When using the "server" output target, you must also include a runtime adapter via the adapter configuration. An adapter will adapt your final build to run on the deployed platform of your choice (Netlify, Vercel, Node.js, Deno, etc).

    To migrate: No action is required for most users. If you currently define an adapter, you will need to also add output: 'server' to your config file to make it explicit that you are building a server. Here is an example of what that change would look like for someone deploying to Netlify:

    import { defineConfig } from 'astro/config';
import netlify from '@astrojs/netlify/functions';

export default defineConfig({
  adapter: netlify(),
+ output: 'server',
});

  • #3973 5a23483ef Thanks @matthewp! - Adds support for Astro.clientAddress

    The new Astro.clientAddress property allows you to get the IP address of the requested user.

    

    This property is only available when building for SSR, and only if the adapter you are using supports providing the IP address. If you attempt to access the property in a SSG app it will throw an error.
    

    • 



0.2.4


Patch Changes



0.2.3


Patch Changes



0.2.2


Patch Changes



0.2.1


Patch Changes



0.2.0


Minor Changes