Astro 6.1 Brings Fine-Grained Image Control and Smarter i18n Routing

Astro 6.1 Brings Fine-Grained Image Control and Smarter i18n Routing

lschvn4 min read

Astro 6.1 dropped on March 31, and while it's not as dramatic a release as Astro 6.0's experimental Rust compiler, it ships three targeted improvements that address real friction points for content-heavy sites deployed at the edge.

Sharp Image Service Gets Encoder-Level Controls

The most practically useful change: you can now set codec-specific defaults for Astro's built-in Sharp image pipeline directly in astro.config.mjs. Before 6.1, you could control per-image quality, but the underlying encoder options, MozJPEG level, WebP effort, AVIF chroma subsampling, PNG compression, were fixed.

In 6.1, with astro/assets/services/sharp, you get:

// astro.config.mjs
export default defineConfig({
  image: {
    service: {
      config: {
        jpeg: { mozjpeg: true },
        webp: { effort: 4 },
        avif: { effort: 3, chromaSubsampling: '4:2:0' },
        png: { compressionLevel: 9 }
      }
    }
  }
});

These become defaults for compile-time image generation. Per-image quality set on <Image />, <Picture />, or getImage() still takes precedence, the hierarchy is preserved.

For sites generating hundreds of variant images at build time, the WebP effort and AVIF settings in particular can meaningfully shift the size/quality tradeoff without touching every image call.

SmartyPants Gets an Options Object

Astro has long supported SmartyPants for automatic typographic refinement in Markdown. 6.1 surfaces the full retext-smartypants options object:

export default defineConfig({
  markdown: {
    smartypants: {
      backticks: 'all',
      dashes: 'oldschool',
      ellipses: 'unspaced',
      openingQuotes: { double: '«', single: '' },
      closingQuotes: { double: '»', single: '' },
      quotes: false
    }
  }
});

This matters for sites with localization requirements or strict typographic standards, French, German, and Nordic languages have specific quotation conventions that the boolean-only config couldn't express. The oldschool dash mode (-- for en-dash) is another long-requested option.

i18n Fallback Routes Now Visible to Integrations

The third change is invisible to end users but matters for the ecosystem: integrations can now see fallback routes generated for i18n configurations using fallbackType: 'rewrite'. Previously, these routes existed in the runtime but weren't exposed via the astro:routes:resolved hook. Integrations that build route indexes, most notably the sitemap integration, would miss generated fallback routes, producing incomplete sitemaps for multilingual sites.

6.1 adds fallbackRoutes to the IntegrationResolvedRoute type:

'astro:routes:resolved': ({ routes }) => {
  for (const route of routes) {
    for (const fallback of route.fallbackRoutes) {
      console.log(fallback.pathname) // e.g. /fr/about/
    }
  }
}

The Cloudflare Effect

Astro joined Cloudflare in January 2026, and the 6.1 release is consistent with that direction: content-heavy sites deployed on Workers/Pages, image optimization at the edge, typographic polish that serves readability. The team is no longer spread across funding concerns and can focus on the framework's core positioning. Astro remains MIT-licensed and platform-agnostic, but the roadmap increasingly reflects what Cloudflare's infrastructure makes easy.

Upgrade with:

npm install astro@latest

Frequently Asked Questions

Related articles

More coverage with overlapping topics and tags.

Next.js v16.3.0-Canary: Prefetch Controls, Dedup Improvements, and a New Dev Overlay
frameworks

Next.js v16.3.0-Canary: Prefetch Controls, Dedup Improvements, and a New Dev Overlay

Next.js 16.3.0-canary brings fine-grained prefetch configuration, better deduping for the 'use cache' directive, and a redesigned blocking route dev overlay, with sccache now bootstrapped via cargo-binstall.
Astro 6 Takes Center Stage: Rust Compiler, Live Content, and a Cloudflare Future
frameworks

Astro 6 Takes Center Stage: Rust Compiler, Live Content, and a Cloudflare Future

Astro 6.0 and 6.1 land within weeks of each other, bringing an experimental Rust compiler, request-time content collections, a built-in Fonts API, CSP tooling, and deeper Cloudflare integration, all while the framework doubles its adoption for the third year running.
Rolldown 1.1.4 Disables `experimental.lazyBarrel` by Default Again, One Month After 1.1.0 Made It Default-On
tooling

Rolldown 1.1.4 Disables `experimental.lazyBarrel` by Default Again, One Month After 1.1.0 Made It Default-On

Rolldown [v1.1.4](https://github.com/rolldown/rolldown/releases/tag/v1.1.4), published 2026-07-01T14:02:02Z, ships one feature change and 19 bug fixes. The feature change is a partial reversal of the [v1.1.0 default-flip](https://github.com/rolldown/rolldown/releases/tag/v1.1.0) that landed on 2026-06-03: `experimental.lazyBarrel` is now disabled by default again, after four weeks of correctness reports against the default-on behaviour. The release also hardens the dev-mode path by forcing `lazyBarrel` off whenever `experimental.devMode` is set (PR [#10060](https://github.com/rolldown/rolldown/pull/10060)), on top of the existing force-off for `treeshake`. The default-flip revert (PR [#10071](https://github.com/rolldown/rolldown/pull/10071)) and the dev-mode fix both author as one line each: "disable `experimental.lazyBarrel` by default" and "fix(dev): disable lazy barrel in dev mode", and the root-cause tracking is the new [issue #10085](https://github.com/rolldown/rolldown/issues/10085) "Tracking strictExecutionOrder correctness and architecture issues", opened the day after the release. The release follows [Rolldown v1.1.3](https://github.com/rolldown/rolldown/releases/tag/v1.1.3) (2026-06-24) and is the first release since 1.1.0 to touch the lazyBarrel config surface.

Comments

Log in Log in to join the conversation.

No comments yet. Be the first to share your thoughts.