withastro/astro astro@3.5.0 on GitHub

Minor Changes

#8869 f5bdfa272 Thanks @matthewp! - ## Integration Hooks to add Middleware

It's now possible in Astro for an integration to add middleware on behalf of the user. Previously when a third party wanted to provide middleware, the user would need to create a src/middleware.ts file themselves. Now, adding third-party middleware is as easy as adding a new integration.

For integration authors, there is a new addMiddleware function in the astro:config:setup hook. This function allows you to specify a middleware module and the order in which it should be applied:

// my-package/middleware.js
import { defineMiddleware } from 'astro:middleware';

export const onRequest = defineMiddleware(async (context, next) => {
  const response = await next();

  if (response.headers.get('content-type') === 'text/html') {
    let html = await response.text();
    html = minify(html);
    return new Response(html, {
      status: response.status,
      headers: response.headers,
    });
  }

  return response;
});

You can now add your integration's middleware and specify that it runs either before or after the application's own defined middleware (defined in src/middleware.{js,ts})

// my-package/integration.js
export function myIntegration() {
  return {
    name: 'my-integration',
    hooks: {
      'astro:config:setup': ({ addMiddleware }) => {
        addMiddleware({
          entrypoint: 'my-package/middleware',
          order: 'pre',
        });
      },
    },
  };
}

#8854 3e1239e42 Thanks @natemoo-re! - Provides a new, experimental build cache for Content Collections as part of the Incremental Build RFC. This includes multiple refactors to Astro's build process to optimize how Content Collections are handled, which should provide significant performance improvements for users with many collections.
Users building a static site can opt-in to preview the new build cache by adding the following flag to your Astro config:
```
// astro.config.mjs
export default {
  experimental: {
    contentCollectionCache: true,
  },
};
```
When this experimental feature is enabled, the files generated from your content collections will be stored in the cacheDir (by default, node_modules/.astro) and reused between builds. Most CI environments automatically restore files in node_modules/ by default.
In our internal testing on the real world Astro Docs project, this feature reduces the bundling step of astro build from 133.20s to 10.46s, about 92% faster. The end-to-end astro build process used to take 4min 58s and now takes just over 1min for a total reduction of 80%.
If you run into any issues with this experimental feature, please let us know!
You can always bypass the cache for a single build by passing the --force flag to astro build.
```
astro build --force
```
#8963 fda3a0213 Thanks @matthewp! - Form support in View Transitions router
The <ViewTransitions /> router can now handle form submissions, allowing the same animated transitions and stateful UI retention on form posts that are already available on <a> links. With this addition, your Astro project can have animations in all of these scenarios:
- Clicking links between pages.
- Making stateful changes in forms (e.g. updating site preferences).
- Manually triggering navigation via the navigate() API.
This feature is opt-in for semver reasons and can be enabled by adding the handleForms prop to the ` component:
```
---
// src/layouts/MainLayout.astro
import { ViewTransitions } from 'astro:transitions';
---

<html>
  <head>
    
    <ViewTransitions handleForms />
  </head>
  <body>
    
  </body>
</html>
```
Just as with links, if you don't want the routing handling a form submission, you can opt out on a per-form basis with the data-astro-reload property:
```
---
// src/components/Contact.astro
---

<form class="contact-form" action="/request" method="post" data-astro-reload>
  
</form>
```
Form support works on post method="get" and method="post" forms.
#8954 f0031b0a3 Thanks @Princesseuh! - Updates the Image Services API to now delete original images from the final build that are not used outside of the optimization pipeline. For users with a large number of these images (e.g. thumbnails), this should reduce storage consumption and deployment times.
#8984 26b1484e8 Thanks @Princesseuh! - Adds a new property propertiesToHash to the Image Services API to allow specifying which properties of getImage() / <Image /> / <Picture /> should be used for hashing the result files when doing local transformations. For most services, this will include properties such as src, width or quality that directly changes the content of the generated image.
#9010 100b61ab5 Thanks @jasikpark! - The <Picture /> component will now use jpg and jpeg respectively as fallback formats when the original image is in those formats.
#8974 143bacf39 Thanks @ematipico! - Experimental support for i18n routing.
Astro's experimental i18n routing API allows you to add your multilingual content with support for configuring a default language, computing relative page URLs, and accepting preferred languages provided by your visitor's browser. You can also specify fallback languages on a per-language basis so that your visitors can always be directed to existing content on your site.
Enable the experimental routing option by adding an i18n object to your Astro configuration with a default location and a list of all languages to support:
```
// astro.config.mjs
import { defineConfig } from 'astro/config';

export default defineConfig({
  experimental: {
    i18n: {
      defaultLocale: 'en',
      locales: ['en', 'es', 'pt-br'],
    },
  },
});
```
Organize your content folders by locale depending on your i18n.routingStrategy, and Astro will handle generating your routes and showing your preferred URLs to your visitors.
```
├── src
│   ├── pages
│   │   ├── about.astro
│   │   ├── index.astro
│   │   ├── es
│   │   │   ├── about.astro
│   │   │   ├── index.astro
│   │   ├── pt-br
│   │   │   ├── about.astro
│   │   │   ├── index.astro
```
Compute relative URLs for your links with getRelativeLocaleUrl from the new astro:i18n module:
```
---
import { getRelativeLocaleUrl } from 'astro:i18n';
const aboutUrl = getRelativeLocaleUrl('pt-br', 'about');
---

<p>Learn more <a href={aboutURL}>About</a> this site!</p>
```
Enabling i18n routing also provides two new properties for browser language detection: Astro.preferredLocale and Astro.preferredLocaleList. These combine the browser's Accept-Langauge header, and your site's list of supported languages and can be used to automatically respect your visitor's preferred languages.
Read more about Astro's experimental i18n routing in our documentation.
#8951 38e21d127 Thanks @bluwy! - Prefetching is now supported in core
You can enable prefetching for your site with the prefetch: true config. It is enabled by default when using View Transitions and can also be used to configure the prefetch behaviour used by View Transitions.
You can enable prefetching by setting prefetch:true in your Astro config:
```
// astro.config.js
import { defineConfig } from 'astro/config';

export default defineConfig({
  prefetch: true,
});
```
This replaces the @astrojs/prefetch integration, which is now deprecated and will eventually be removed.
Visit the Prefetch guide for more information.
#8903 c5010aad3 Thanks @horo-fox! - Adds experimental support for multiple shiki themes with the new markdown.shikiConfig.experimentalThemes option.

Patch Changes

#9016 1ecc9aa32 Thanks @Princesseuh! - Add ability to "Click to go editor" on auditted elements in the dev overlay
#9029 29b83e9e4 Thanks @Princesseuh! - Use UInt8Array instead of Buffer for both the input and return values of the transform() hook of the Image Service API to ensure compatibility with non-Node runtimes.
This change is unlikely to affect you, but if you were previously relying on the return value being a Buffer, you may convert an UInt8Array to a Buffer using Buffer.from(your_array).
Updated dependencies [c5010aad3]:
- @astrojs/markdown-remark@3.4.0