Skip to content

Latest commit

 

History

History
182 lines (106 loc) · 8.23 KB

CHANGELOG.md

File metadata and controls

182 lines (106 loc) · 8.23 KB

@astrojs/node

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

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.

0.1.10

Patch Changes

0.1.9

Patch Changes

0.1.8

Patch Changes

0.1.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.1.6

Patch Changes

0.1.5

Patch Changes

0.1.4

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

Patch Changes

0.1.2

Patch Changes

0.1.1

Patch Changes

0.1.0

Minor Changes

Patch Changes

0.0.2-next.0

Patch Changes