michael/astro
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
astro/packages/integrations/netlify/CHANGELOG.md
Houston (Bot) db4095d3f5
[ci] release (#7624) 
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
2023-07-13 21:43:11 +08:00

42 KiB
Raw Blame History

@astrojs/netlify

2.4.0

Minor Changes

  • #7615 f21357b69 Thanks @ematipico! - The Netlify adapter builds to a single function by default. Astro 2.7 added support for splitting your build into separate entry points per page. If you use this configuration, the Netlify adapter will generate a separate function for each page. This can help reduce the size of each function so they are only bundling code used on that page.

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

export default defineConfig({
  output: 'server',
  adapter: netlify(),
  build: {
    split: true,
  },
});

Patch Changes

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

2.3.0

Minor Changes

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

    This adds support for the redirects RFC in the Netlify adapter, including a new @astrojs/netlify/static adapter for static sites.

    No changes are necessary when using SSR. Simply use configured redirects and the adapter will update your _redirects file.

Patch Changes

2.2.3

Patch Changes

2.2.2

Patch Changes

2.2.1

Patch Changes

2.2.0

Minor Changes

Patch Changes

2.1.3

Patch Changes

2.1.2

Patch Changes

2.1.1

Patch Changes

2.1.0

Minor Changes

Patch Changes

2.0.0

Major Changes

  • #5584 9963c6e4d & #5842 c4b0cb8bf Thanks @wulinsheng123 and @natemoo-re! - Breaking Change: client assets are built to an _astro directory in the build output directory. Previously these were built to various locations, including assets/, chunks/ and the root of build output.

    You can control this location with the new build configuration option named assets.

  • #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

2.0.0-beta.4

Patch Changes

2.0.0-beta.3

Patch Changes

2.0.0-beta.2

Major Changes

  • #5842 c4b0cb8bf Thanks @natemoo-re! - Breaking Change: client assets are built to an _astro directory in the build output directory. Previously these were built to various locations, including assets/, chunks/ and the root of build output.

    You can control this location with the new build configuration option named assets.

  • #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

2.0.0-beta.1

Patch Changes

2.0.0-beta.0

Major Changes

1.3.0

Minor Changes

  • #5297 d2960984c Thanks @natemoo-re! - Introduces the experimental Prerender API.

    Note

    This API is not yet stable and is subject to possible breaking changes!

    • Deploy an Astro server without sacrificing the speed or cacheability of static HTML.
    • The Prerender API allows you to statically prerender specific pages/ at build time.

    Usage

    • First, run astro build --experimental-prerender or enable experimental: { prerender: true } in your astro.config.mjs file.
    • Then, include export const prerender = true in any file in the pages/ directory that you wish to prerender.

1.2.2

Patch Changes

1.2.1

Patch Changes

1.2.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: '...',
          },
        });
      },
    },
  };
}

1.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.

Patch Changes

  • #4842 812658ad2 Thanks @bluwy! - Add missing dependencies, support strict dependency installation (e.g. pnpm)

1.0.4

Patch Changes

1.0.3

Patch Changes

1.0.2

Patch Changes

1.0.1

Patch Changes

1.0.0

Major Changes

Patch Changes

  • Updated dependencies [04ad44563]:
    • @astrojs/webapi@1.0.0

0.5.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.4.10

Patch Changes

0.4.9

Patch Changes

0.4.8

Patch Changes

0.4.7

Patch Changes

  • #3734 4acd245d Thanks @bholmesdev! - Fix: append shim to top of built file to avoid "can't read process of undefined" issues

0.4.6

Patch Changes

0.4.5

Patch Changes

0.4.4

Patch Changes

0.4.3

Patch Changes

0.4.2

Patch Changes

  • #3503 207f58d1 Thanks @williamtetlow! - Alias from 'astro' imports to '@astro/types' Update Deno and Netlify integrations to handle vite.resolves.alias as an array

0.4.1

Patch Changes

  • Updated dependencies [4de53ecc]:
    • @astrojs/webapi@0.12.0

0.4.0

Minor Changes

0.3.4

Patch Changes

0.3.3

Patch Changes

0.3.2

Patch Changes

0.3.1

Patch Changes

0.3.0

Minor Changes

0.2.3

Patch Changes

0.2.2

Patch Changes

0.2.1

Patch Changes

0.2.0

Minor Changes

  • 732ea388 Thanks @FredKSchott! - Improve the Netlify adapter:

    1. Remove site config requirement
    2. Fix an issue where query params were being stripped
    3. Pass the event body to the request object

Patch Changes

0.1.1-beta.1

Patch Changes

0.1.1-beta.0

Patch Changes

0.1.0

Minor Changes

0.0.2

Patch Changes

  • #2879 80034c6c Thanks @matthewp! - Netlify Adapter

    This change adds a Netlify adapter that uses Netlify Functions. You can use it like so:

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

export default defineConfig({
  adapter: netlify(),
});