github withastro/astro astro@1.5.0

latest releases: @astrojs/svelte@6.0.1, astro@4.16.13, @astrojs/solid-js@4.4.3...
2 years ago

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.

  • #4986 ebd364e39 Thanks @bluwy! - ## New properties for API routes

    In API routes, you can now get the site, generator, url, clientAddress, props, and redirect fields on the APIContext, which is the first parameter passed to an API route. This was done to make the APIContext more closely align with the Astro global in .astro pages.

    For example, here's how you might use the clientAddress, which is the user's IP address, to selectively allow users.

    export function post({ clientAddress, request, redirect }) {
      if (!allowList.has(clientAddress)) {
        return redirect('/not-allowed');
      }
    }

    Check out the docs for more information on the newly available fields: https://docs.astro.build/en/core-concepts/endpoints/#server-endpoints-api-routes

  • #4959 0ea6187f9 Thanks @Princesseuh! - Added support for updating TypeScript settings automatically when using astro add

    The astro add command will now automatically update your tsconfig.json with the proper TypeScript settings needed for the chosen frameworks.

    For instance, typing astro add solid will update your tsconfig.json with the following settings, per Solid's TypeScript guide:

    {
      "compilerOptions": {
        "jsx": "preserve",
        "jsxImportSource": "solid-js"
      }
    }
  • #4947 a5e3ecc80 Thanks @JuanM04! - - Added isRestart and addWatchFile to integration step isRestart.

    • Restart dev server automatically when tsconfig changes.
  • #4986 ebd364e39 Thanks @bluwy! - ## Support passing a custom status code for Astro.redirect

    New in this minor is the ability to pass a status code to Astro.redirect. By default it uses 302 but now you can pass another code as the second argument:

    ---
    // This page was moved
    return Astro.redirect('/posts/new-post-name', 301);
    ---
  • #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: '...',
              },
            });
          },
        },
      };
    }

Patch Changes

  • #5057 baf88ee9e Thanks @bluwy! - Skip JSX tagging for export statements with source

  • #5044 44ea0c6d9 Thanks @JuanM04! - Upgrade Astro compiler to 0.27.1

  • #5059 f7fcdfe62 Thanks @bluwy! - Support strict dependency install for libraries with JSX

  • #5047 1e2799243 Thanks @matthewp! - Update Astro.cookies.set types to allow booleans and numbers

    Note that booleans and numbers were already allowed, they just were not allowed by the type definitions.

Don't miss a new astro release

NewReleases is sending notifications on new releases.