public-backup/astro
1
0
Fork 0
mirror of https://github.com/withastro/astro.git synced 2025-12-05 18:56:38 -06:00
Code Issues Packages Projects Releases Wiki Activity
Files
main
astro/packages/integrations/node/CHANGELOG.md
Houston (Bot) 7a07f0244c [ci] release (#14788) 
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
2025-11-17 14:26:07 -05:00

91 KiB
Raw Permalink Blame History

@astrojs/node

9.5.1

Patch Changes

  • Updated dependencies [9e9c528, 0f75f6b]:
    • @astrojs/internal-helpers@0.7.5

9.5.0

Minor Changes

  • #14441 62ec8ea Thanks @upsuper! - Updates redirect handling to be consistent across static and server output, aligning with the behavior of other adapters.

    Previously, the Node.js adapter used default HTML files with meta refresh tags when in static output. This often resulted in an extra flash of the page on redirect, while also not applying the proper status code for redirections. It's also likely less friendly to search engines.

    This update ensures that configured redirects are always handled as HTTP redirects regardless of output mode, and the default HTML files for the redirects are no longer generated in static output. It makes the Node.js adapter more consistent with the other official adapters.

    No change to your project is required to take advantage of this new adapter functionality. It is not expected to cause any breaking changes. However, if you relied on the previous redirecting behavior, you may need to handle your redirects differently now. Otherwise you should notice smoother redirects, with more accurate HTTP status codes, and may potentially see some SEO gains.

9.4.6

Patch Changes

  • #14514 66a26d7 Thanks @matthewp! - Fixes compatibility issue with older versions of Astro by making getAllowedDomains() call optional and updating peer dependency to require astro@^5.14.3

9.4.5

Patch Changes

  • Updated dependencies [b8ca69b]:
    • @astrojs/internal-helpers@0.7.4

9.4.4

Patch Changes

  • Updated dependencies [1e2499e]:
    • @astrojs/internal-helpers@0.7.3

9.4.3

Patch Changes

9.4.2

Patch Changes

  • Updated dependencies [4d16de7]:
    • @astrojs/internal-helpers@0.7.2

9.4.1

Patch Changes

  • 5fc3c59 Thanks @ematipico! - Fixes a routing bug in standalone mode with trailingSlash set to "always".

9.4.0

Minor Changes

  • #14188 e3422aa Thanks @ascorbic! - Adds support for specifying a host to load prerendered error pages

    By default, if a user defines a custom error page that is prerendered, Astro will load it from the same host as the one that the request is made to. This change allows users to specify a different host for loading prerendered error pages. This can be useful in scenarios such as where the server is running behind a reverse proxy or when prerendered pages are hosted on a different domain.

    To use this feature, set the experimentalErrorPageHost adapter option in your Astro configuration to the desired host URL. For example, if your server is running on localhost and served via a proxy, you can ensure the prerendered error pages are fetched via the localhost URL:

    import { defineConfig } from 'astro/config';
import node from '@astrojs/node';
export default defineConfig({
  adapter: node({
    // If your server is running on localhost and served via a proxy, set the host like this to ensure prerendered error pages are fetched via the localhost URL
    experimentalErrorPageHost: 'http://localhost:4321',
  }),
});

    For more information on enabling and using this experimental feature, see the @astrojs/node adapter docs.

9.3.3

Patch Changes

  • Updated dependencies [0567fb7]:
    • @astrojs/internal-helpers@0.7.1

9.3.2

Patch Changes

  • Updated dependencies [f4e8889]:
    • @astrojs/internal-helpers@0.7.0

9.3.1

Patch Changes

9.3.0

Minor Changes

  • #14012 a125a14 Thanks @florian-lefebvre! - Adds a new experimental configuration option experimentalDisableStreaming to allow you to opt out of Astro's default HTML streaming for pages rendered on demand.

    HTML streaming helps with performance and generally provides a better visitor experience. In most cases, disabling streaming is not recommended.

    However, when you need to disable HTML streaming (e.g. your host only supports non-streamed HTML caching at the CDN level), you can now opt out of the default behavior:

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

export default defineConfig({
  adapter: node({
    mode: 'standalone',
+    experimentalDisableStreaming: true,
  }),
});

  • #13972 db8f8be Thanks @ematipico! - Adds support for the experimental static headers Astro feature.

    When the feature is enabled via the option experimentalStaticHeaders, and experimental Content Security Policy is enabled, the adapter will generate Response headers for static pages, which allows support for CSP directives that are not supported inside a <meta> tag (e.g. frame-ancestors).

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

export default defineConfig({
  adapter: node({
    mode: 'standalone',
    experimentalStaticHeaders: true,
  }),
  experimental: {
    cps: true,
  },
});

9.2.2

Patch Changes

9.2.1

Patch Changes

9.2.0

Minor Changes

  • #13527 2fd6a6b Thanks @ascorbic! - The experimental session API introduced in Astro 5.1 is now stable and ready for production use.

    Sessions are used to store user state between requests for on-demand rendered pages. You can use them to store user data, such as authentication tokens, shopping cart contents, or any other data that needs to persist across requests:

    ---
export const prerender = false; // Not needed with 'server' output
const cart = await Astro.session.get('cart');
---

<a href="/checkout">🛒 {cart?.length ?? 0} items</a>

    Configuring session storage

    Sessions require a storage driver to store the data. The Node, Cloudflare and Netlify adapters automatically configure a default driver for you, but other adapters currently require you to specify a custom storage driver in your configuration.

    If you are using an adapter that doesn't have a default driver, or if you want to choose a different driver, you can configure it using the session configuration option:

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

export default defineConfig({
  adapter: vercel(),
  session: {
    driver: 'upstash',
  },
});

    Using sessions

    Sessions are available in on-demand rendered pages, API endpoints, actions and middleware.

    In pages and components, you can access the session using Astro.session:

    ---
const cart = await Astro.session.get('cart');
---

<a href="/checkout">🛒 {cart?.length ?? 0} items</a>

    In endpoints, actions, and middleware, you can access the session using context.session:

    export async function GET(context) {
  const cart = await context.session.get('cart');
  return Response.json({ cart });
}

    If you attempt to access the session when there is no storage driver configured, or in a prerendered page, the session object will be undefined and an error will be logged in the console:

    ---
export const prerender = true;
const cart = await Astro.session?.get('cart'); // Logs an error. Astro.session is undefined
---

    Upgrading from Experimental to Stable

    If you were previously using the experimental API, please remove the experimental.session flag from your configuration:

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

export default defineConfig({
   adapter: node({
     mode: "standalone",
   }),
-  experimental: {
-    session: true,
-  },
});

    See the sessions guide for more information.

9.1.3

Patch Changes

  • Updated dependencies [042d1de]:
    • @astrojs/internal-helpers@0.6.1

9.1.2

Patch Changes

  • Updated dependencies [1e11f5e]:
    • @astrojs/internal-helpers@0.6.0

9.1.1

Patch Changes

9.1.0

Minor Changes

  • #13145 8d4e566 Thanks @ascorbic! - Automatically configures filesystem storage when experimental session enabled

    If the experimental.session flag is enabled when using the Node adapter, Astro will automatically configure session storage using the filesystem driver. You can still manually configure session storage if you need to use a different driver or want to customize the session storage configuration.

    See the experimental session docs for more information on configuring session storage.

9.0.3

Patch Changes

  • #13223 23094a1 Thanks @ascorbic! - Fixes a bug that caused incorrect redirects for static files with numbers in the file extension

9.0.2

Patch Changes

  • #514 ea4297b Thanks @ascorbic! - Fixes a bug that caused the preview server to ignore wildcard host options

9.0.1

Patch Changes

9.0.0

Major Changes

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

  • #451 167b369 Thanks @ematipico! - Updates send dependency to v1.1.0

Minor Changes

9.0.0-beta.3

Major Changes

9.0.0-beta.2

Major Changes

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

Minor Changes

9.0.0-alpha.1

Major Changes

  • #11679 ea71b90 Thanks @florian-lefebvre! - Adds stable support for astro:env

  • #11770 cfa6a47 Thanks @Princesseuh! - 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

9.0.0-alpha.0

Patch Changes

8.3.4

Patch Changes

8.3.4

Patch Changes

8.3.3

Patch Changes

  • #11535 932bd2e Thanks @matthewp! - Move polyfills up before awaiting the env module in the Node.js adapter.

    Previously the env setting was happening before the polyfills were applied. This means that if the Astro env code (or any dependencies) depended on crypto, it would not be polyfilled in time.

    Polyfills should be applied ASAP to prevent races. This moves it to the top of the Node adapter.

8.3.2

Patch Changes

8.3.1

Patch Changes

8.3.0

Minor Changes

8.2.6

Patch Changes

8.2.5

Patch Changes

8.2.4

Patch Changes

8.2.3

Patch Changes

8.2.2

Patch Changes

8.2.1

Patch Changes

8.2.0

Minor Changes

8.1.0

Minor Changes

8.0.0

Major Changes

  • #9661 d6edc7540864cf5d294d7b881eb886a3804f6d05 Thanks @ematipico! - If host is unset in standalone mode, the server host will now fallback to localhost instead of 127.0.0.1. When localhost is used, the operating system can decide to use either ::1 (ipv6) or 127.0.0.1 (ipv4) itself. This aligns with how the Astro dev and preview server works by default.

    If you relied on 127.0.0.1 (ipv4) before, you can set the HOST environment variable to 127.0.0.1 to explicitly use ipv4. For example, HOST=127.0.0.1 node ./dist/server/entry.mjs.

  • #9661 d6edc7540864cf5d294d7b881eb886a3804f6d05 Thanks @ematipico! - Breaking: Minimum required Astro version is now 4.2.0. Reorganizes internals to be more maintainable.

Patch Changes

7.0.4

Patch Changes

7.0.3

Patch Changes

7.0.2

Patch Changes

7.0.1

Patch Changes

  • #9366 1b4e91898 Thanks @lilnasy! - Updates NPM package to refer to the stable Astro version instead of a beta.

7.0.0

Major Changes

  • #9199 49aa215a0 Thanks @lilnasy! - The internals of the integration have been updated to support Astro 4.0. Make sure to upgrade your Astro version as Astro 3.0 is no longer supported.

7.0.0-beta.1

Major Changes

  • #9199 49aa215a0 Thanks @lilnasy! - The internals of the integration have been updated to support Astro 4.0. Make sure to upgrade your Astro version as Astro 3.0 is no longer supported.

7.0.0-beta.0

Patch Changes

6.1.0

Minor Changes

  • #9125 8f1d50957 Thanks @matthewp! - Automatically sets immutable cache headers for assets served from the /_astro directory.

6.1.0

Minor Changes

  • #9125 8f1d50957 Thanks @matthewp! - Automatically sets immutable cache headers for assets served from the /_astro directory.

6.0.4

Patch Changes

6.0.3

Patch Changes

6.0.2

Patch Changes

  • #8698 47ea310f0 Thanks @Princesseuh! - Use a Node-specific image endpoint to resolve images in dev and Node SSR. This should fix many issues related to getting 404 from the _image endpoint under certain configurations

  • Updated dependencies [31c59ad8b, 47ea310f0, 345808170]:

    • astro@3.2.1

6.0.1

Patch Changes

6.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 148e61d24 Thanks @ematipico! - Reduced the amount of polyfills provided by Astro. Astro will no longer provide (no-op) polyfills for several web apis such as HTMLElement, Image or Document. If you need access to those APIs on the server, we recommend using more proper polyfills available on npm.

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

6.0.0-rc.1

Major Changes

Patch Changes

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

  • 3dc1ca2fa Thanks @Princesseuh! - Reduced the amount of polyfills provided by Astro. Astro will no longer provide (no-op) polyfills for several web apis such as HTMLElement, Image or Document. If you need access to those APIs on the server, we recommend using more proper polyfills available on npm.

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

5.3.6

Patch Changes

5.3.5

Patch Changes

5.3.4

Patch Changes

5.3.3

Patch Changes

5.3.2

Patch Changes

5.3.1

Patch Changes

5.3.0

Minor Changes

  • #7385 8e2923cc6 Thanks @ematipico! - Astro.locals is now exposed to the adapter API. Node Adapter can now pass in a locals object in the SSR handler middleware.

Patch Changes

5.2.0

Minor Changes

  • #7227 4929332c3 Thanks @alex-sherwin! - Fixes NodeJS adapter for multiple set-cookie headers and combining AstroCookies and Response.headers cookies

Patch Changes

5.1.4

Patch Changes

5.1.3

Patch Changes

5.1.2

Patch Changes

5.1.1

Patch Changes

5.1.0

Minor Changes

Patch Changes

5.0.4

Patch Changes

5.0.3

Patch Changes

5.0.2

Patch Changes

5.0.1

Patch Changes

5.0.0

Major Changes

  • #5782 1f92d64ea Thanks @Princesseuh! - Remove support for Node 14. Minimum supported Node version is now >=16.12.0

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

Minor Changes

  • #5832 2303f9514 Thanks @HiDeoo! - Add support for serving well-known URIs with the @astrojs/node SSR adapter

Patch Changes

5.0.0-beta.1

See changes in 5.0.0-beta.1

Major Changes

  • #5782 1f92d64ea Thanks @Princesseuh! - Remove support for Node 14. Minimum supported Node version is now >=16.12.0

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

Minor Changes

  • #5832 2303f9514 Thanks @HiDeoo! - Add support for serving well-known URIs with the @astrojs/node SSR adapter

Patch Changes

5.0.0-beta.0

See changes in 5.0.0-beta.0

Major Changes

Patch Changes

4.0.0

Patch Changes

3.1.1

Patch Changes

3.1.0

Minor Changes

  • #5418 aa16b6ceb Thanks @jbanety! - Sometimes Astro sends a ReadableStream as a response and it raise an error TypeError: body is not async iterable.

    I added a function to get a response iterator from different response types (sourced from apollo-client).

    With this, node adapter can handle all the Astro response types.

  • #5421 12236dbc0 Thanks @Scttpr! - Allow HOST env variable to be provided at runtime

Patch Changes

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

2.0.2

Patch Changes

2.0.1

Patch Changes

2.0.0

Major Changes

  • #5056 e55af8a23 Thanks @matthewp! - # Standalone mode for the Node.js adapter

    New in @astrojs/node is support for standalone mode. With standalone mode you can start your production server without needing to write any server JavaScript yourself. The server starts simply by running the script like so:

    node ./dist/server/entry.mjs

    To enable standalone mode, set the new mode to 'standalone' option in your Astro config:

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

export default defineConfig({
  output: 'server',
  adapter: nodejs({
    mode: 'standalone',
  }),
});

    See the @astrojs/node documentation to learn all of the options available in standalone mode.

    Breaking change

    This is a semver major change because the new mode option is required. Existing @astrojs/node users who are using their own HTTP server framework such as Express can upgrade by setting the mode option to 'middleware' in order to build to a middleware mode, which is the same behavior and API as before.

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

export default defineConfig({
  output: 'server',
  adapter: nodejs({
    mode: 'middleware',
  }),
});

Minor Changes

  • #5056 e55af8a23 Thanks @matthewp! - # Adapter support for astro preview

    Adapters are now about to support the astro preview command via a new integration option. The Node.js adapter @astrojs/node is the first of the built-in adapters to gain support for this. What this means is that if you are using @astrojs/node you can new preview your SSR app by running:

    npm run preview

    Adapter API

    We will be updating the other first party Astro adapters to support preview over time. Adapters can opt in to this feature by providing the previewEntrypoint via the setAdapter function in astro:config:done hook. The Node.js adapter's code looks like this:

    export default function() {
  return {
		name: '@astrojs/node',
		hooks: {
			'astro:config:done': ({ setAdapter, config }) => {
        setAdapter({
          name: '@astrojs/node',
          serverEntrypoint: '@astrojs/node/server.js',
+          previewEntrypoint: '@astrojs/node/preview.js',
          exports: ['handler'],
        });

        // more here
      }
    }
  };
}

    The previewEntrypoint is a module in the adapter's package that is a Node.js script. This script is run when astro preview is run and is charged with starting up the built server. See the Node.js implementation in @astrojs/node to see how that is implemented.

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

1.0.1

Patch Changes

1.0.0

Major Changes

Patch Changes

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

0.2.1

Patch Changes

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

Patch Changes

0.1.6

Patch Changes

0.1.5

Patch Changes

0.1.4

Patch Changes

0.1.3

Patch Changes

0.1.2

Patch Changes

0.1.1

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(),
});

0.0.2-next.0

Patch Changes