Astro.config.mjs

0 views

Skip to first unread message

Exequiel Mondragon

unread,

Aug 3, 2024, 5:02:17 PM8/3/24

to ginthyosandser

Astro supports several file formats for its JavaScript configuration file: astro.config.js, astro.config.mjs, astro.config.cjs and astro.config.ts. We recommend using .mjs in most cases or .ts if you want to write TypeScript in your config file.

Vite-specific import.meta properties, like import.meta.env or import.meta.glob, are not accessible from your configuration file. We recommend alternatives like dotenv or fast-glob for these respective use cases. In addition, tsconfig path aliases will not be resolved. Use relative paths for module imports in this file.

For code that Astro processes, like imported JavaScript or CSS files, you can customise output filenames using entryFileNames, chunkFileNames, and assetFileNames in a vite.build.rollupOptions entry in your astro.config.* file.

I was working on a project the day before, pushing git commits that would spin up in Netlify okay.The very next day I come to my project not loading at all in local host with the following terminal error. I believe it has something to do with dependancies that were included with the 'Astro Stone' starter template I used at the beginning, or something inside of the astro.config.mjs file not being found in a new version requested???

By default, the Astro app server is deployed to a single region defined in your sst.config.ts or passed in via the --region flag. Alternatively, you can choose to deploy to the edge. When deployed to the edge, loaders/actions are running on edge location that is physically closer to the end user. In this case, the app server is deployed to AWS Lambda@Edge.

Note that, in the case you have a centralized database, Edge locations are often far away from your database. If you are querying your database in your loaders/actions, you might experience much longer latency when deployed to the edge.

Due to the CloudFront limit of 25 path pattern per distribution, it's impractical to create one path for each route in your Astro app. To work around this limitation, all routes are first checked against the S3 cache before being directed to the Lambda function for server rendering. This method utilizes the CloudFront origin group, with the S3 bucket serving as the primary origin and the server function as the failover origin. Note that the origin group can only support GET, HEAD, and OPTIONS request methods. To support other request methods, you should specify the route patterns in the astro.config.mjs file as the serverRoutes parameter on the adapter registration method (ie aws(serverRoutes: [])).

Astro natively supports streaming, allowing a page to be broken down into chunks. These chunks can be sent over the network in sequential order and then incrementally rendered in the browser. This process can significantly enhances page performance and allow larger responses sizes than buffered responses, but there is a slight performance overhead. To enable streaming, set the responseMode property on the adapter registration method within the astro.config.mjs to stream. The default response mode is buffer which will wait for the entire response to be generated before sending it to the client.

The AstroSite construct allows you to set the environment variables in your Astro app based on outputs from other constructs in your SST app. So you don't have to hard code the config from your backend. Let's look at how.

On sst deploy, the Astro app server is deployed to a Lambda function, and the AstroSite's environment values are set as Lambda function environment variables. In this case, process.env.API_URL will be available at runtime.

If you enabled the edge option, the Astro app server will instead get deployed to a Lambda@Edge function. We have an issue here, AWS Lambda@Edge does not support runtime environment variables. To get around this limitation, we insert a snippet to the top of your app server:

And at deploy time, after the referenced resources have been created, the API in this case, a CloudFormation custom resource will update the app server's code and replace the placeholder _SST_FUNCTION_ENVIRONMENT_ with the actual value:

Since the AstroSite construct deploys your Astro app to your AWS account, it's very convenient to access other resources in your AWS account. AstroSite provides a simple way to grant permissions to access specific AWS resources.

Starting v2.35.0, sourcemaps are enabled by default in the astro-sst adapter. When your Astro app builds, it'll generate the sourcemap files alongside your code. SST uploads these files to the bootstrap bucket.

You can specify additional domain names for the site url. Note that the certificate for these names will not be automatically generated, so the certificate option must be specified. Also note that you need to manually create the Route 53 records for the alternate domain names.

Note that the certificate needs be created in the us-east-1(N. Virginia) region as required by AWS CloudFront, and validated. After the Distribution has been created, create a CNAME DNS record for your domain name with the Distribution's URL as the value. Here are more details on configuring SSL Certificate on externally hosted domains.

CloudFront has a limit of 20 cache policies per AWS account. This is a hard limit, and cannot be increased. If you plan to deploy multiple Astro sites, you can have the constructs share the same cache policies by reusing them across sites.

When deployed to a single region, instead of sending the request to the server function directly, you can send the request to API Gateway and have API Gateway proxy the request to the server function. With this setup, you can use features like authorizers to protect the server function.

By default, Astro deployments relying on the Sharp library use a bundled version of the library. This bundle is very large which can cause the startup time of the SSR Lambda function to be slower. Utilizing a Lambda layer can help reduce the size of the SSR Lambda function and improve startup time.

To use a Lambda layer, you must first create or download a layer containing the Sharp library, and place the layer directory or ZIP in your project.Recommended pre-built Sharp layer repositories: ph200/sharp-layer, Umkus/lambda-layer-sharp

This typically occurs when the site is deployed in the regional mode. It's likely because the request method was not GET, and the requested route was not specified in the serverRoutes property in the astro.config.mjs file. To resolve this, add a route pattern to the serverRoutes property that matches the requested route.

List of file options to specify cache control and content type for cached files. These file options are appended to the default file options so it's possible to override the default file options by specifying an overlapping file pattern.

While deploying, SST waits for the CloudFront cache invalidation process to finish. This ensures that the new content will be served once the deploy command finishes. However, this process can sometimes take more than 5 mins. For non-prod environments it might make sense to pass infalse. That'll skip waiting for the cache to invalidate and speed up the deploy process.

Secure the server function URL using AWS IAM authentication. By default, the server function URL is publicly accessible. When this flag is enabled, the server function URL will require IAM authorization, and a Lambda@Edge function will sign the requests. Be aware that this introduces added latency to the requests.

Default : By default, the cache policy is configured to cache all responses fromthe server rendering Lambda based on the query-key only. If you're usingcookie or header based authentication, you'll need to override thecache policy to cache based on those values as well.

Import the certificate for the domain. By default, SST will create a certificate with the domain name. The certificate will be created in theus-east-1(N. Virginia) region as required by AWS CloudFront.

Configure if sourcemaps are generated when the function is bundled for production. Since they increase payload size and potentially cold starts they are not generated by default. They are always generated during local development mode.

If enabled, modules that are dynamically imported will be bundled as their own files with common dependencies placed in shared chunks. This can help drastically reduce cold starts as your function grows in size.

We are very excited to announce the release of @storyblok/astro! Using Storyblok in your Astro project is now much easier and faster than before. Thanks to the powerful Astro Integration API and our new module, you can get up and running in a matter of minutes.

For each Astro component that should be linked to its equivalent in your Storyblok Space, you can use the storyblokEditable() function on its root element, passing the blok property that they receive and enabling communication with the Storyblok Bridge. Furthermore, you can use the StoryblokComponent to dynamically load any of the components that you registered globally.

The Storyblok Bridge is automatically activated by default. If you would like to disable it or enable it conditionally (e.g. depending on the environment) you can set the bridge parameter to false in astro.config.mjs.

Since Astro is not a reactive JavaScript framework and renders everything as HTML, the Storyblok Bridge will not provide real-time editing as you may know it from other frameworks. However, it automatically refreshes the site for you whenever you save or publish a story.

Have you tried building the Astro app w/o using Edgio? This looks like an Astro build erro and npx astro build should be able to reproduce it. If you look at the build error screenshot, the input reference to file://C:*** looks invalid. Perhaps a configuration issue in your astro.config.mjs file?