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