michael/astro
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
astro/packages/integrations/cloudflare/CHANGELOG.md
Houston (Bot) c23ddb9ab3
[ci] release (#8501) 
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
2023-09-12 14:29:39 -04:00

66 KiB
Raw Blame History

@astrojs/cloudflare

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

  • Updated dependencies [5b1e39ef6]:
    • astro@2.10.5

6.6.2

Patch Changes

6.6.1

Patch Changes

  • Updated dependencies [f21357b69, 86e19c7cf]:
    • @astrojs/underscore-redirects@0.2.0
    • astro@2.8.2

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

  • #5993 9855db676 Thanks @matthewp! - Support for prerendering in the Cloudflare integration

    This fixes prerendering in the Cloudflare adapter. Now any prerendered routes are added to the _routes.json config so that the worker script is skipped for those routes.

  • Updated dependencies [b53e0717b, 60b32d585, 883e0cc29, dabce6b8c, aedf23f85]:

    • astro@2.0.2

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

  • #5301 a79a37cad Thanks @bluwy! - Fix environment variables usage in worker output and warn if environment variables are accessedd too early

  • Updated dependencies [88c1bbe3a, a79a37cad]:

    • astro@1.6.5

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