#10067989ea63bb2a5a670021541198aa70b8dc7c4bd2f Thanks @ematipico! - Fixes a regression in the astro:i18n module, where the functions getAbsoluteLocaleUrl and getAbsoluteLocaleUrlList returned a URL with double slash with a certain combination of options.
The existing configuration options, file and directory, either build all of your HTML pages as files matching the route name (e.g. /about.html) or build all your files as index.html within a nested directory structure (e.g. /about/index.html), respectively. It was not previously possible to control the HTML file built on a per-file basis.
One limitation of build.format: 'file' is that it cannot create index.html files for any individual routes (other than the base path of /) while otherwise building named files. Creating explicit index pages within your file structure still generates a file named for the page route (e.g. src/pages/about/index.astro builds /about.html) when using the file configuration option.
Rather than make a breaking change to allow build.format: 'file' to be more flexible, we decided to create a new build.format: 'preserve'.
The new format will preserve how the filesystem is structured and make sure that is mirrored over to production. Using this option:
#9143041fdd5c89920f7ccf944b095f29e451f78b0e28 Thanks @ematipico! - Adds experimental support for a new i18n domain routing option ("domains") that allows you to configure different domains for individual locales in entirely server-rendered projects.
To enable this in your project, first configure your server-rendered project’s i18n routing with your preferences if you have not already done so. Then, set the experimental.i18nDomains flag to true and add i18n.domains to map any of your supported locales to custom URLs:
//astro.config.mjs"
import { defineConfig } from'astro/config';
exportdefaultdefineConfig({
site: 'https://example.com',
output: 'server', // required, with no prerendered pages
adapter: node({
mode: 'standalone',
}),
i18n: {
defaultLocale: 'en',
locales: ['es', 'en', 'fr', 'ja'],
routing: {
prefixDefaultLocale: false,
},
domains: {
fr: 'https://fr.example.com',
es: 'https://example.es',
},
},
experimental: {
i18nDomains: true,
},
});
With "domains" configured, the URLs emitted by getAbsoluteLocaleUrl() and getAbsoluteLocaleUrlList() will use the options set in i18n.domains.
import { getAbsoluteLocaleUrl } from'astro:i18n';
getAbsoluteLocaleUrl('en', 'about'); // will return "https://example.com/about"
getAbsoluteLocaleUrl('fr', 'about'); // will return "https://fr.example.com/about"
getAbsoluteLocaleUrl('es', 'about'); // will return "https://example.es/about"
getAbsoluteLocaleUrl('ja', 'about'); // will return "https://example.com/ja/about"
Similarly, your localized files will create routes at corresponding URLs:
The file /en/about.astro will be reachable at the URL https://example.com/about.
The file /fr/about.astro will be reachable at the URL https://fr.example.com/about.
The file /es/about.astro will be reachable at the URL https://example.es/about.
The file /ja/about.astro will be reachable at the URL https://example.com/ja/about.
See our Internationalization Guide for more details and limitations on this experimental routing feature.
Now, you can use the standard  syntax in Markdown files for images colocated in the same folder: no relative specifier required!
There is no need to update your project; your existing images will still continue to work. However, you may wish to remove any relative specifiers from these Markdown images as they are no longer necessary:
<!-- This dog lives in the same folder as my article! -->
#98162a44c8f93201958fba2d1e83046eabcaef186b7c Thanks @Princesseuh! - Adds telemetry for when apps are toggled in the dev toolbar. This data is completely anonymous and only the names of built-in apps are shared with us. This data will help us monitor how much the dev toolbar is used and which apps are used more. For more information on how Astro collects telemetry, visit the following page: https://astro.build/telemetry/
#974173d74402007896204ee965f6553dc83b3dec8d2f Thanks @taktran! - Fixes an issue where dot files were not copied over from the public folder to the output folder, when build command was run in a folder other than the root of the project.
Helper functions for converting Node.js HTTP request and response objects to web-compatible Request and Response objects are now provided as static methods on the NodeApp class.
#9638f1a61268061b8834f39a9b38bca043ae41caed04 Thanks @ematipico! - Adds a new i18n.routing config option redirectToDefaultLocale to disable automatic redirects of the root URL (/) to the default locale when prefixDefaultLocale: true is set.
In projects where every route, including the default locale, is prefixed with /[locale]/ path, this property allows you to control whether or not src/pages/index.astro should automatically redirect your site visitors from / to /[defaultLocale].
You can now opt out of this automatic redirection by setting redirectToDefaultLocale: false:
astro.config.mjs
exportdefaultdefineConfig({
i18n: {
defaultLocale: 'en',
locales: ['en', 'fr'],
routing: {
prefixDefaultLocale: true,
redirectToDefaultLocale: false,
},
},
});
#96718521ff77fbf7e867701cc30d18253856914dbd1b Thanks @bholmesdev! - Removes the requirement for non-content files and assets inside content collections to be prefixed with an underscore. For files with extensions like .astro or .css, you can now remove underscores without seeing a warning in the terminal.
src/content/blog/
post.mdx
_styles.css
_Component.astro
styles.css
Component.astro
Continue to use underscores in your content collections to exclude individual content files, such as drafts, from the build output.
#95673a4d5ec8001ebf95c917fdc0d186d29650533d93 Thanks @OliverSpeir! - Improves the a11y-missing-content rule and error message for audit feature of dev-overlay. This also fixes an error where this check was falsely reporting accessibility errors.
#9643e9a72d9a91a3741566866bcaab11172cb0dc7d31 Thanks @blackmann! - Adds a new markdown.shikiConfig.transformers config option. You can use this option to transform the Shikiji hast (AST format of the generated HTML) to customize the final HTML. Also updates Shikiji to the latest stable version.
Enabling this feature overrides the default prefetch behavior globally to prerender links on the client according to your prefetch configuration. Instead of appending a <link> tag to the head of the document or fetching the page with JavaScript, a <script> tag will be appended with the corresponding speculation rules.
Client side prerendering requires browser support. If the Speculation Rules API is not supported, prefetch will fallback to the supported strategy.
See the Prefetch Guide for more prefetch options and usage.
Enabling this feature ensures that all routes in your project follow the same, predictable route priority order rules. In particular, this avoids an issue where redirects or injected routes (e.g. from an integration) would always take precedence over local route definitions, making it impossible to override some routes locally.
The following table shows which route builds certain page URLs when file-based routes, injected routes, and redirects are combined as shown below:
File-based route: /blog/post/[pid]
File-based route: /[page]
Injected route: /blog/[...slug]
Redirect: /blog/tags/[tag] -> /[tag]
Redirect: /posts -> /blog
URLs are handled by the following routes:
Page
Current Behavior
Global Routing Priority Behavior
/blog/tags/astro
Injected route /blog/[...slug]
Redirect to /tags/[tag]
/blog/post/0
Injected route /blog/[...slug]
File-based route /blog/post/[pid]
/posts
File-based route /[page]
Redirect to /blog
In the event of route collisions, where two routes of equal route priority attempt to build the same URL, Astro will log a warning identifying the conflicting routes.
Now, routes with more defined path segments will take precedence over less specific routes.
For example, /blog/posts/[pid].astro (3 path segments) takes precedence over /blog/[...slug].astro (2 path segments). This means that:
/pages/blog/posts/[id].astro will build routes of the form /blog/posts/1 and /blog/posts/a
/pages/blog/[...slug].astro will build routes of a variety of forms, including blog/1 and /blog/posts/1/a, but will not build either of the previous routes.
For a complete list of Astro’s routing priority rules, please see the routing guide. This should not be a breaking change, but you may wish to inspect your built routes to ensure that your project is unaffected.
Tailwind config file ending in .ts, .mts or .cts will now be used instead of creating a new tailwind.config.mjs when the tailwind integration is added using astro add tailwind.
