Upgrade to Astro v6

This guide will help you migrate from Astro v5 to Astro v6.

Need to upgrade an older project to v5 first? See our older migration guide.

Need to see the v5 docs? Visit this older version of the docs site (unmaintained v5.xx snapshot).

Upgrade Astro

Update your project’s version of Astro to the latest version using your package manager:

npm

# Upgrade Astro and official integrations together
npx @astrojs/upgrade

pnpm

# Upgrade Astro and official integrations together
pnpm dlx @astrojs/upgrade

Yarn

# Upgrade Astro and official integrations together
yarn dlx @astrojs/upgrade

You can also upgrade your Astro integrations manually if needed, and you may also need to upgrade other dependencies in your project.

Need to continue?

After upgrading Astro, you may not need to make any changes to your project at all!

But, if you notice errors or unexpected behavior, please check below for what has changed that might need updating in your project.

Astro v6.0 includes potentially breaking changes, as well as the removal and deprecation of some features.

If your project doesn’t work as expected after upgrading to v6.0, check this guide for an overview of all breaking changes and instructions on how to update your codebase.

See the Astro changelog for full release notes.

Dependency Upgrades

Any major upgrades to Astro’s dependencies may cause breaking changes in your project.

Legacy

The following features are now considered legacy features. They should function normally but are no longer recommended and are in maintenance mode. They will see no future improvements and documentation will not be updated. These features will eventually be deprecated, and then removed entirely.

Deprecated

The following deprecated features are no longer supported and are no longer documented. Please update your project accordingly.

Some deprecated features may temporarily continue to function until they are completely removed. Others may silently have no effect, or throw an error prompting you to update your code.

Removed

The following features have now been entirely removed from the code base and can no longer be used. Some of these features may have continued to work in your project even after deprecation. Others may have silently had no effect.

Projects now containing these removed features will be unable to build, and there will no longer be any supporting documentation prompting you to remove these features.

Removed: legacy content collections

Implementación PR: fix: remove legacy content collections (#14407)

In Astro 5.x, it was still possible to use the Content Collections API first introduced in Astro v2.0, either through a legacy configuration flag or via built-in backwards compatibility. These methods allowed you to upgrade to Astro v5 even if you were not yet ready or able to update your content collections to the new Content Layer API.

Astro v6.0 removes this previously deprecated Content Collections API support entirely, including the legacy.collections flag. All content collections must now use the Content Layer API introduced in Astro v5.0 that powers all content collections. No backwards compatibility support is available.

What should I do?

If you had previously enabled the legacy flag, you must remove it.

astro.config.mjs

import { defineConfig } from 'astro/config';

export default defineConfig({
  legacy: {
    collections: true,
  }
})

Additionally, if you did not upgrade your collections for Astro v5.0, ensure that your content collections are fully updated for the updated API.

Astro v5.x included some automatic backwards compatibility to allow content collections to continue to work even if they had not been updated to use the new API. Therefore, your v5 collections may contain one or more legacy features that need updating to the newer API for v6, even if your project was previously error-free.

If you have content collections errors or warnings after upgrading to v6, use the following list to help you identify and upgrade any legacy features that may exist in your code.

If you have…

no content collections configuration file

Create src/content.config.ts and define your collections in it.

a configuration file located at src/content/config.ts

Rename and move this file to src/content.config.ts

a collection that does not define a loader

Import Astro’s built-in glob() loader and define the pattern and base for your collection entries:

src/content.config.ts

import { defineCollection, z } from 'astro:content';
import { glob } from 'astro/loaders';

const blog = defineCollection({
  loader: glob({ pattern: '**/[^_]*.{md,mdx}', base: "./src/data/blog" }),
  schema: z.object({
    title: z.string(),
    description: z.string(),
    pubDate: z.coerce.date(),
    updatedDate: z.coerce.date().optional(),
  }),
});

a collection that defines a collection type (type: 'content' or type: 'data')

There are no longer different types of collections. This must be deleted from your collection definition.

src/content.config.ts

import { defineCollection, z } from 'astro:content';
import { glob } from 'astro/loaders';

const blog = defineCollection({
  // For content layer you no longer define a `type`
  type: 'content',
  loader: glob({ pattern: '**/[^_]*.{md,mdx}', base: "./src/data/blog" }),
  schema: z.object({
    title: z.string(),
    description: z.string(),
    pubDate: z.coerce.date(),
    updatedDate: z.coerce.date().optional(),
  }),
});

legacy collection querying methods getDataEntryById() and getEntryBySlug()

Replace both methods with getEntry().

legacy collection querying and rendering methods that depend on a slug property

Previously the id was based on the filename, and there was a slug property that could be used in a URL. Now the CollectionEntry type id is a slug. If you need access to the filename (previously available as the id) use the filePath property. Replace instances of slug with id.:

src/pages/[slug].astro

---
export async function getStaticPaths() {
  const posts = await getCollection('blog');
  return posts.map((post) => ({
    params: { slug: post.slug },
    params: { slug: post.id },
    props: post,
  }));
}
---

content rendered using entry.render()

Collection entries no longer have a render() method. Instead, import the render() function from astro:content and use render(entry):

src/pages/index.astro

---
import { getEntry, render } from 'astro:content';

const post = await getEntry('blog', params.slug);

const { Content, headings } = await post.render();
const { Content, headings } = await render(post);
---
<Content />

See the Astro v5 upgrade guide for previous guidance about backwards compatibility of legacy collections in Astro v5 and upgrading to the new Content Layer API.

Removed: <ViewTransitions /> component

Implementación PR: Remove deprecated ViewTransitions component (#14400)

In Astro 5.0, the <ViewTransitions /> component was renamed to <ClientRouter /> to clarify the role of the component. The new name makes it more clear that the features you get from Astro’s <ClientRouter /> routing component are slightly different from the native CSS-based MPA router. However, a deprecated version of the <ViewTransitions /> component still existed and may have functioned in Astro 5.x.

Astro 6.0 removes the <ViewTransitions /> component entirely and it can no longer be used in your project. Update to the <ClientRouter /> component to continue to use these features.

What should I do?

Replace all occurrences of the ViewTransitions import and component with ClientRouter:

src/layouts/MyLayout.astro

import { ViewTransitions } from 'astro:transitions';
import { ClientRouter } from 'astro:transitions';

<html>
  <head>
    ...
   <ViewTransitions />
   <ClientRouter />
  </head>
</html>

Read more about view transitions and client-side routing in Astro.

Removed: emitESMImage()

Implementación PR: feat!: remove emitESMImage() (#14426)

In Astro 5.6.2, the emitESMImage() function was deprecated in favor of emitImageMetadata(), which removes two deprecated arguments that were not meant to be exposed for public use: _watchMode and experimentalSvgEnabled.

Astro 6.0 removes emitESMImage() entirely. Update to emitImageMetadata() to keep your current behavior.

What should I do?

Replace all occurrences of the emitESMImage() with emitImageMetadata() and remove unused arguments:

import { emitESMImage } from 'astro/assets/utils';
import { emitImageMetadata } from 'astro/assets/utils';

const imageId = '/images/photo.jpg';
const result = await emitESMImage(imageId, false, false);
const result = await emitImageMetadata(imageId);

Read more about emitImageMetadata().

Changed Defaults

Some default behavior has changed in Astro v5.0 and your project code may need updating to account for these changes.

In most cases, the only action needed is to review your existing project’s deployment and ensure that it continues to function as you expect, making updates to your code as necessary. In some cases, there may be a configuration setting to allow you to continue to use the previous default behavior.

Breaking Changes

The following changes are considered breaking changes in Astro v5.0. Breaking changes may or may not provide temporary backwards compatibility. If you were using these features, you may have to update your code as recommended in each entry.

Community Resources

Know a good resource for Astro v5.0? Edit this page and add a link below!

Known Issues

Please check Astro’s issues on GitHub for any reported issues, or to file an issue yourself.