Home Original page

astro/packages/astro/CHANGELOG.md at main · JCazorla90/astro

2.0.2

Patch Changes

2.0.1

Patch Changes

2.0.0

Note This is a detailed changelog of all changes in Astro v2.
See our upgrade guide for an overview of steps needed to upgrade an existing project.

Major Changes

  • #5687 e2019be6f Thanks @bholmesdev! - Give remark and rehype plugins access to user frontmatter via frontmatter injection. This means data.astro.frontmatter is now the complete Markdown or MDX document's frontmatter, rather than an empty object.

    This allows plugin authors to modify existing frontmatter, or compute new properties based on other properties. For example, say you want to compute a full image URL based on an imageSrc slug in your document frontmatter:

    export function remarkInjectSocialImagePlugin() {
  return function (tree, file) {
    const { frontmatter } = file.data.astro;
    frontmatter.socialImageSrc = new URL(frontmatter.imageSrc, 'https://my-blog.com/').pathname;
  };
}

    When using Content Collections, you can access this modified frontmatter using the remarkPluginFrontmatter property returned when rendering an entry.

    Migration instructions

    Plugin authors should now check for user frontmatter when applying defaults.

    For example, say a remark plugin wants to apply a default title if none is present. Add a conditional to check if the property is present, and update if none exists:

    export function remarkInjectTitlePlugin() {
  return function (tree, file) {
    const { frontmatter } = file.data.astro;
+    if (!frontmatter.title) {
      frontmatter.title = 'Default title';
+    }
  }
}

    This differs from previous behavior, where a Markdown file's frontmatter would always override frontmatter injected via remark or reype.

  • #5891 05caf445d Thanks @bholmesdev! - Remove deprecated Markdown APIs from Astro v0.X. This includes getHeaders(), the .astro property for layouts, and the rawContent() and compiledContent() error messages for MDX.

  • #5778 49ab4f231 Thanks @bluwy! - Remove proload to load the Astro config. It will now use NodeJS and Vite to load the config only.

  • #5728 8fb28648f Thanks @natemoo-re! - The previously experimental features --experimental-error-overlay and --experimental-prerender, both added in v1.7.0, are now the default.

    You'll notice that the error overlay during astro dev has a refreshed visual design and provides more context for your errors.

    The prerender feature is now enabled by default when using output: 'server'. To prerender a particular page, add export const prerender = true to your frontmatter.

    Warning Integration authors that previously relied on the exact structure of Astro's v1.0 build output may notice some changes to our output file structure. Please test your integrations to ensure compatability. Users that have configured a custom vite.build.rollupOptions.output.chunkFileNames should ensure that their Astro project is configured as an ESM Node project. Either include "type": "module" in your root package.json file or use the .mjs extension for chunkFileNames.

  • #5782 1f92d64ea Thanks @Princesseuh! - Remove support for Node 14. Minimum supported Node version is now >=16.12.0

  • #5771 259a539d7 Thanks @matthewp! - Removes support for astroFlavoredMarkdown

    In 1.0 Astro moved the old Astro Flavored Markdown (also sometimes called Components in Markdown) to a legacy feature. This change removes the legacy.astroFlavoredMarkdown option completely.

    In 2.0 this feature will not be available in Astro at all. We recommend migration to MDX for those were still using this feature in 1.x.

  • #5941 304823811 Thanks @bholmesdev! - Content collections: Introduce a new slug frontmatter field for overriding the generated slug. This replaces the previous slug() collection config option from Astro 1.X and the 2.0 beta.

    When present in a Markdown or MDX file, this will override the generated slug for that entry.

    # src/content/blog/post-1.md
---
title: Post 1
+ slug: post-1-custom-slug
---

    Astro will respect this slug in the generated slug type and when using the getEntryBySlug() utility:

    ---
import { getEntryBySlug } from 'astro:content';

// Retrieve `src/content/blog/post-1.md` by slug with type safety
const post = await getEntryBySlug('blog', 'post-1-custom-slug');
---

    Migration

    If you relied on the slug() config option, you will need to move all custom slugs to slug frontmatter properties in each collection entry.

    Additionally, Astro no longer allows slug as a collection schema property. This ensures Astro can manage the slug property for type generation and performance. Remove this property from your schema and any relevant slug() configuration:

    const blog = defineCollection({
  schema: z.object({
-   slug: z.string().optional(),
  }),
- slug({ defaultSlug, data }) {
-   return data.slug ?? defaultSlug;
- },
})

  • #5753 302e0ef8f Thanks @bluwy! - Default preview host to localhost instead of 127.0.0.1. This allows the static server and integration preview servers to serve under ipv6.

  • #5716 dd56c1941 Thanks @bluwy! - Remove MDX Fragment hack. This was used by @astrojs/mdx to access the Fragment component, but isn't required anymore since @astrojs/mdx v0.12.1.

  • #5584 9963c6e4d & #5842 c4b0cb8bf Thanks @wulinsheng123 and @natemoo-re! - Breaking Change: client assets are built to an _astro directory in the build output directory. Previously these were built to various locations, including assets/, chunks/ and the root of build output.

    You can control this location with the new build configuration option named assets.

  • #5893 be901dc98 Thanks @matthewp! - Rename getEntry to getEntryBySlug

    This change moves getEntry to getEntryBySlug and accepts a slug rather than an id.

    In order to improve support in [id].astro routes, particularly in SSR where you do not know what the id of a collection is. Using getEntryBySlug instead allows you to map the [id] param in your route to the entry. You can use it like this:

    ---
import { getEntryBySlug } from 'astro:content';

const entry = await getEntryBySlug('docs', Astro.params.id);

if (!entry) {
  return new Response(null, {
    status: 404,
  });
}
---

<!-- You have an entry! Use it! -->

  • #5685 f6cf92b48 Thanks @bluwy! - Upgrade to Vite 4. Please see its migration guide for more information.

  • #5724 16c7d0bfd Thanks @bluwy! - Remove outdated Vue info log. Remove toString support for RenderTemplateResult.

  • #5684 a9c292026 & #5769 93e633922 Thanks @bholmesdev! - Refine Markdown and MDX configuration options for ease-of-use.

    • Markdown

      • Replace the extendDefaultPlugins option with a gfm boolean and a smartypants boolean. These are enabled by default, and can be disabled to remove GitHub-Flavored Markdown and SmartyPants.

      • Ensure GitHub-Flavored Markdown and SmartyPants are applied whether or not custom remarkPlugins or rehypePlugins are configured. If you want to apply custom plugins and remove Astro's default plugins, manually set gfm: false and smartypants: false in your config.

    • Migrate extendDefaultPlugins to gfm and smartypants

      You may have disabled Astro's built-in plugins (GitHub-Flavored Markdown and Smartypants) with the extendDefaultPlugins option. This has now been split into 2 flags to disable each plugin individually:

      • markdown.gfm to disable GitHub-Flavored Markdown
      • markdown.smartypants to disable SmartyPants
      // astro.config.mjs
import { defineConfig } from 'astro/config';

export default defineConfig({
  markdown: {
-   extendDefaultPlugins: false,
+   smartypants: false,
+   gfm: false,
  }
});

      Additionally, applying remark and rehype plugins no longer disables gfm and smartypants. You will need to opt-out manually by setting gfm and smartypants to false.

    • MDX

      • Support all Markdown configuration options (except drafts) from your MDX integration config. This includes syntaxHighlighting and shikiConfig options to further customize the MDX renderer.

      • Simplify extendPlugins to an extendMarkdownConfig option. MDX options will default to their equivalent in your Markdown config. By setting extendMarkdownConfig to false, you can "eject" to set your own syntax highlighting, plugins, and more.

    • Migrate MDX's extendPlugins to extendMarkdownConfig

      You may have used the extendPlugins option to manage plugin defaults in MDX. This has been replaced by 3 flags:

      • extendMarkdownConfig (true by default) to toggle Markdown config inheritance. This replaces the extendPlugins: 'markdown' option.
      • gfm (true by default) and smartypants (true by default) to toggle GitHub-Flavored Markdown and SmartyPants in MDX. This replaces the extendPlugins: 'defaults' option.

  • #5717 a3a7fc929 Thanks @bluwy! - Remove style.postcss Astro config. Refactor tailwind integration to configure through vite instead. Also disables autoprefixer in dev.

  • #5825 52209ca2a Thanks @bholmesdev! - Baseline the experimental contentCollections flag. You're free to remove this from your astro config!

    import { defineConfig } from 'astro/config';

export default defineConfig({
- experimental: { contentCollections: true }
})

  • #5707 5eba34fcc Thanks @bluwy! - Remove deprecated Astro global APIs, including Astro.resolve, Astro.fetchContent, and Astro.canonicalURL.

    • Astro.resolve

      You can resolve asset paths using import instead. For example:

      ---
import 'style.css';
import imageUrl from './image.png';
---

<img src={imageUrl} />

      See the v0.25 migration guide for more information.

    • Astro.fetchContent

      Use Astro.glob instead to fetch markdown files, or migrate to the Content Collections feature.

      let allPosts = await Astro.glob('./posts/*.md');

    • Astro.canonicalURL

      Use Astro.url instead to construct the canonical URL.

      const canonicalURL = new URL(Astro.url.pathname, Astro.site);

  • #5608 899214298 Thanks @konojunya! - A trailing slash will not be automatically appended to import.meta.env.SITE. Instead, it will be the value of the site config as is. This may affect usages of ${import.meta.env.SITE}image.png, which will need to be updated accordingly.

  • #5707 5eba34fcc Thanks @bluwy! - Remove buildConfig option parameter from integration astro:build:start hook in favour of the build.config option in the astro:config:setup hook.

    export default function myIntegration() {
  return {
    name: 'my-integration',
    hooks: {
      'astro:config:setup': ({ updateConfig }) => {
        updateConfig({
          build: {
            client: '...',
            server: '...',
            serverEntry: '...',
          },
        });
      },
    },
  };
}

  • #5862 1ca81c16b Thanks @bluwy! - Remove unused exports

Minor Changes

  • #5901 a342a486c Thanks @bluwy! - The fallback Svelte preprocessor will only be applied if a custom preprocess option is not passed to the svelte() integration option, or in the svelte.config.js file.

    To support IDE autocompletion, or if you're migrating from @astrojs/svelte v1, you can create a svelte.config.js file with:

    import { vitePreprocess } from '@astrojs/svelte';

export default {
  preprocess: vitePreprocess(),
};

    This file will also be generated by astro add svelte by default.

  • #5786 c2180746b Thanks @bholmesdev! - Move generated content collection types to a .astro directory. This replaces the previously generated src/content/types.generated.d.ts file.

    If you're using Git for version control, we recommend ignoring this generated directory by adding .astro to your .gitignore.

    Astro will also generate the TypeScript reference path to include .astro types in your project. This will update your project's src/env.d.ts file, or write one if none exists.

  • #5826 840412128 Thanks @bholmesdev! - Allow Zod objects, unions, discriminated unions, intersections, and transform results as content collection schemas.

    Migration

    Astro requires a z.object(...) wrapper on all content collection schemas. Update your content collections config like so:

    // src/content/config.ts
import { z, defineCollection } from 'astro:content';

const blog = defineCollection({
- schema: {
+ schema: z.object({
  ...
})

  • #5823 1f49cddf9 Thanks @delucis! - Generate content types when running astro check

  • #5832 2303f9514 Thanks @HiDeoo! - Add support for serving well-known URIs with the @astrojs/node SSR adapter

Patch Changes

2.0.0-beta.4

See changes in 2.0.0-beta.4

Major Changes

  • #5941 304823811 Thanks @bholmesdev! - Content collections: Introduce a new slug frontmatter field for overriding the generated slug. This replaces the previous slug() collection config option from Astro 1.X and the 2.0 beta.

    When present in a Markdown or MDX file, this will override the generated slug for that entry.

    # src/content/blog/post-1.md
---
title: Post 1
+ slug: post-1-custom-slug
---

    Astro will respect this slug in the generated slug type and when using the getEntryBySlug() utility:

    ---
import { getEntryBySlug } from 'astro:content';

// Retrieve `src/content/blog/post-1.md` by slug with type safety
const post = await getEntryBySlug('blog', 'post-1-custom-slug');
---

    Migration

    If you relied on the slug() config option, you will need to move all custom slugs to slug frontmatter properties in each collection entry.

    Additionally, Astro no longer allows slug as a collection schema property. This ensures Astro can manage the slug property for type generation and performance. Remove this property from your schema and any relevant slug() configuration:

    const blog = defineCollection({
  schema: z.object({
-   slug: z.string().optional(),
  }),
- slug({ defaultSlug, data }) {
-   return data.slug ?? defaultSlug;
- },
})

Patch Changes

2.0.0-beta.3

See changes in 2.0.0-beta.3

Major Changes

  • #5891 05caf445d Thanks @bholmesdev! - Remove deprecated Markdown APIs from Astro v0.X. This includes getHeaders(), the .astro property for layouts, and the rawContent() and compiledContent() error messages for MDX.

  • #5893 be901dc98 Thanks @matthewp! - Move getEntry to getEntryBySlug

    This change moves getEntry to getEntryBySlug and accepts a slug rather than an id.

    In order to improve support in [id].astro routes, particularly in SSR where you do not know what the id of a collection is. Using getEntryBySlug instead allows you to map the [id] param in your route to the entry. You can use it like this:

    ---
import { getEntryBySlug } from 'astro:content';

const entry = await getEntryBySlug('docs', Astro.params.id);

if (!entry) {
  return new Response(null, {
    status: 404,
  });
}
---

<!-- You have an entry! Use it! -->

  • #5608 899214298 Thanks @konojunya! - A trailing slash will not be automatically appended to import.meta.env.SITE. Instead, it will be the value of the site config as is. This may affect usages of ${import.meta.env.SITE}image.png, which will need to be updated accordingly.

  • #5862 1ca81c16b Thanks @bluwy! - Remove unused exports

Minor Changes

  • #5901 a342a486c Thanks @bluwy! - The fallback Svelte preprocessor will only be applied if a custom preprocess option is not passed to the svelte() integration option, or in the svelte.config.js file.

    To support IDE autocompletion, or if you're migrating from @astrojs/svelte v1, you can create a svelte.config.js file with:

    import { vitePreprocess } from '@astrojs/svelte';

export default {
  preprocess: vitePreprocess(),
};

    This file will also be generated by astro add svelte by default.

Patch Changes

2.0.0-beta.2

See changes in 2.0.0-beta.2

Major Changes

  • #5782 1f92d64ea Thanks @Princesseuh! - Remove support for Node 14. Minimum supported Node version is now >=16.12.0

  • #5753 302e0ef8f Thanks @bluwy! - Default preview host to localhost instead of 127.0.0.1. This allows the static server and integration preview servers to serve under ipv6.

  • #5842 c4b0cb8bf Thanks @natemoo-re! - Breaking Change: client assets are built to an _astro directory in the build output directory. Previously these were built to various locations, including assets/, chunks/ and the root of build output.

    You can control this location with the new build configuration option named assets.

  • #5825 52209ca2a Thanks @bholmesdev! - Baseline the experimental contentCollections flag. You're free to remove this from your astro config!

    import { defineConfig } from 'astro/config';

export default defineConfig({
- experimental: { contentCollections: true }
})

Minor Changes

  • #5786 c2180746b Thanks @bholmesdev! - Move generated content collection types to a .astro directory. This replaces the previously generated src/content/types.generated.d.ts file.

    If you're using Git for version control, we recommend ignoring this generated directory by adding .astro to your .gitignore.

    Astro will also generate the TypeScript reference path to include .astro types in your project. This will update your project's src/env.d.ts file, or write one if none exists.

  • #5826 840412128 Thanks @bholmesdev! - Allow Zod objects, unions, discriminated unions, intersections, and transform results as content collection schemas.

    Migration

    Astro requires a z.object(...) wrapper on all content collection schemas. Update your content collections config like so:

    // src/content/config.ts
import { z, defineCollection } from 'astro:content';

const blog = defineCollection({
- schema: {
+ schema: z.object({
  ...
})

  • #5823 1f49cddf9 Thanks @delucis! - Generate content types when running astro check

  • #5832 2303f9514 Thanks @HiDeoo! - Add support for serving well-known URIs with the @astrojs/node SSR adapter

Patch Changes

2.0.0-beta.1

See changes in 2.0.0-beta.1

Major Changes

  • #5778 49ab4f231 Thanks @bluwy! - Remove proload to load the Astro config. It will now use NodeJS and Vite to load the config only.

  • #5771 259a539d7 Thanks @matthewp! - Removes support for astroFlavoredMarkdown

    In 1.0 Astro moved the old Astro Flavored Markdown (also sometimes called Components in Markdown) to a legacy feature. This change removes the legacy.astroFlavoredMarkdown option completely.

    In 2.0 this feature will not be available in Astro at all. We recommend migration to MDX for those were still using this feature in 1.x.

  • #5717 a3a7fc929 Thanks @bluwy! - Remove style.postcss Astro config. Refactor tailwind integration to configure through vite instead. Also disables autoprefixer in dev.

Minor Changes

  • #5769 93e633922 Thanks @bholmesdev! - Introduce a smartypants flag to opt-out of Astro's default SmartyPants plugin.

    {
  markdown: {
    smartypants: false,
  }
}

    Migration

    You may have disabled Astro's built-in plugins (GitHub-Flavored Markdown and Smartypants) with the extendDefaultPlugins option. This has now been split into 2 flags to disable each plugin individually:

    • markdown.gfm to disable GitHub-Flavored Markdown
    • markdown.smartypants to disable SmartyPants
    // astro.config.mjs
import { defineConfig } from 'astro/config';

export default defineConfig({
  markdown: {
-   extendDefaultPlugins: false,
+   smartypants: false,
+   gfm: false,
  }
});

Patch Changes

2.0.0-beta.0

See changes in 2.0.0-beta.0

Major Changes

  • #5687 e2019be6f Thanks @bholmesdev! - Give remark and rehype plugins access to user frontmatter via frontmatter injection. This means data.astro.frontmatter is now the complete Markdown or MDX document's frontmatter, rather than an empty object.

    This allows plugin authors to modify existing frontmatter, or compute new properties based on other properties. For example, say you want to compute a full image URL based on an imageSrc slug in your document frontmatter:

    export function remarkInjectSocialImagePlugin() {
  return function (tree, file) {
    const { frontmatter } = file.data.astro;
    frontmatter.socialImageSrc = new URL(frontmatter.imageSrc, 'https://my-blog.com/').pathname;
  };
}

    Content Collections - new remarkPluginFrontmatter property

    We have changed inject frontmatter to modify frontmatter in our docs to improve discoverability. This is based on support forum feedback, where "injection" is rarely the term used.

    To reflect this, the injectedFrontmatter property has been renamed to remarkPluginFrontmatter. This should clarify this plugin is still separate from the data export Content Collections expose today.

    Migration instructions

    Plugin authors should now check for user frontmatter when applying defaults.

    For example, say a remark plugin wants to apply a default title if none is present. Add a conditional to check if the property is present, and update if none exists:

    export function remarkInjectTitlePlugin() {
  return function (tree, file) {
    const { frontmatter } = file.data.astro;
+    if (!frontmatter.title) {
      frontmatter.title = 'Default title';
+    }
  }
}

    This differs from previous behavior, where a Markdown file's frontmatter would always override frontmatter injected via remark or reype.

  • #5728 8fb28648f Thanks @natemoo-re! - The previously experimental features --experimental-error-overlay and --experimental-prerender, both added in v1.7.0, are now the default.

    You'll notice that the error overlay during astro dev has a refreshed visual design and provides more context for your errors.

    The prerender feature is now enabled by default when using output: 'server'. To prerender a particular page, add export const prerender = true to your frontmatter.

    Warning Integration authors that previously relied on the exact structure of Astro's v1.0 build output may notice some changes to our output file structure. Please test your integrations to ensure compatability. Users that have configured a custom vite.build.rollupOptions.output.chunkFileNames should ensure that their Astro project is configured as an ESM Node project. Either include "type": "module" in your root package.json file or use the .mjs extension for chunkFileNames.

  • #5716 dd56c1941 Thanks @bluwy! - Remove MDX Fragment hack. This was used by @astrojs/mdx to access the Fragment component, but isn't require anymore since @astrojs/mdx v0.12.1.

  • #5685 f6cf92b48 Thanks @bluwy! - Upgrade to Vite 4. Please see its migration guide for more information.

  • #5724 16c7d0bfd Thanks @bluwy! - Remove outdated Vue info log. Remove toString support for RenderTemplateResult.

  • #5684 a9c292026 Thanks @bholmesdev! - Refine Markdown and MDX configuration options for ease-of-use.

    Markdown

    • Remove remark-smartypants from Astro's default Markdown plugins.
    • Replace the extendDefaultPlugins option with a simplified gfm boolean. This is enabled by default, and can be disabled to remove GitHub-Flavored Markdown.
    • Ensure GitHub-Flavored Markdown is applied whether or not custom remarkPlugins or rehypePlugins are configured. If you want to apply custom plugins and remove GFM, manually set gfm: false in your config.

    MDX

    • Support all Markdown configuration options (except drafts) from your MDX integration config. This includes syntaxHighlighting and shikiConfig options to further customize the MDX renderer.
    • Simplify extendDefaults to an extendMarkdownConfig option. MDX options will default to their equivalent in your Markdown config. By setting extendMarkdownConfig to false, you can "eject" to set your own syntax highlighting, plugins, and more.

    Migration

    To preserve your existing Markdown and MDX setup, you may need some configuration changes:

    Smartypants manual installation

    Smartypants has been removed from Astro's default setup. If you rely on this plugin, install remark-smartypants and apply to your astro.config.*:

    // astro.config.mjs
import { defineConfig } from 'astro/config';
+ import smartypants from 'remark-smartypants';

export default defineConfig({
  markdown: {
+   remarkPlugins: [smartypants],
  }
});

    Migrate extendDefaultPlugins to gfm

    You may have disabled Astro's built-in plugins (GitHub-Flavored Markdown and Smartypants) with the extendDefaultPlugins option. Since Smartypants has been removed, this has been renamed to gfm.

    // astro.config.mjs
import { defineConfig } from 'astro/config';

export default defineConfig({
  markdown: {
-   extendDefaultPlugins: false,
+   gfm: false,
  }
});

    Additionally, applying remark and rehype plugins no longer disables gfm. You will need to opt-out manually by setting gfm to false.

    Migrate MDX's extendPlugins to extendMarkdownConfig

    You may have used the extendPlugins option to manage plugin defaults in MDX. This has been replaced by 2 flags:

    • extendMarkdownConfig (true by default) to toggle Markdown config inheritance. This replaces the extendPlugins: 'markdown' option.
    • gfm (true by default) to toggle GitHub-Flavored Markdown in MDX. This replaces the extendPlugins: 'defaults' option.

  • #5707 5eba34fcc Thanks @bluwy! - Remove deprecated Astro global APIs, including Astro.resolve, Astro.fetchContent, and Astro.canonicalURL.

    Astro.resolve

    You can resolve asset paths using import instead. For example:

    ---
import 'style.css';
import imageUrl from './image.png';
---

<img src={imageUrl} />

    See the v0.25 migration guide for more information.

    Astro.fetchContent

    Use Astro.glob instead to fetch markdown files, or migrate to the Content Collections feature.

    let allPosts = await Astro.glob('./posts/*.md');

    Astro.canonicalURL

    Use Astro.url instead to construct the canonical URL.

    const canonicalURL = new URL(Astro.url.pathname, Astro.site);

  • #5707 5eba34fcc Thanks @bluwy! - Remove buildConfig option parameter from integration astro:build:start hook in favour of the build.config option in the astro:config:setup hook.

    export default function myIntegration() {
  return {
    name: 'my-integration',
    hooks: {
      'astro:config:setup': ({ updateConfig }) => {
        updateConfig({
          build: {
            client: '...',
            server: '...',
            serverEntry: '...',
          },
        });
      },
    },
  };
}

Patch Changes

1.9.2

Patch Changes

1.9.1

Patch Changes

  • adad7e966 Thanks @matthewp! - Fix for hoisted scripts in project with spaces in the file path

1.9.0

Minor Changes

  • #5666 bf210f784 Thanks @bholmesdev! - Correctly handle spaces and capitalization in src/content/ file names. This introduces github-slugger for slug generation to ensure slugs are usable by getStaticPaths. Changes:
    • Resolve spaces and capitalization: collection/Entry With Spaces.md becomes collection/entry-with-spaces.
    • Truncate /index paths to base URL: collection/index.md becomes collection

Patch Changes

1.8.0

Minor Changes

Patch Changes

1.7.2

Patch Changes

1.7.1

Patch Changes

  • #5617 33dcaa05b Thanks @bholmesdev! - Fix error message when using Content Collections and an out-of-date @astrojs/mdx integration

1.7.0

Minor Changes

  • #5297 d2960984c Thanks @natemoo-re! - Introduces the experimental Prerender API.

    Note This API is not yet stable and is subject to possible breaking changes!

    • Deploy an Astro server without sacrificing the speed or cacheability of static HTML.
    • The Prerender API allows you to statically prerender specific pages/ at build time.

    Usage

    • First, run astro build --experimental-prerender or enable experimental: { prerender: true } in your astro.config.mjs file.
    • Then, include export const prerender = true in any file in the pages/ directory that you wish to prerender.

  • #5495 31ec84797 Thanks @Princesseuh! - Add a new error overlay designed by @doodlemarks! This new overlay should be much more informative, clearer, astro-y, and prettier than the previous one.

  • #5291 5ec0f6ed5 Thanks @bholmesdev! - Introduce Content Collections experimental API

    • Organize your Markdown and MDX content into easy-to-manage collections.
    • Add type safety to your frontmatter with schemas.
    • Generate landing pages, static routes, and SSR endpoints from your content using the collection query APIs.

  • #5564 dced4a8a2 Thanks @riywo! - Add server.headers option

  • #5341 6b156dd3b Thanks @alexpdraper! - Allow setting domain when deleting cookies

Patch Changes

1.6.15

Patch Changes

1.6.14

Patch Changes

1.6.13

Patch Changes

1.6.12

Patch Changes

1.6.11

Patch Changes

1.6.10

Patch Changes

1.6.9

Patch Changes

1.6.8

Patch Changes

1.6.7

Patch Changes

1.6.6

Patch Changes

1.6.5

Patch Changes

1.6.4

Patch Changes

  • #5290 b2b291d29 Thanks @matthewp! - Handle base configuration in adapters

    This allows adapters to correctly handle base configuration. Internally Astro now matches routes when the URL includes the base.

    Adapters now also have access to the removeBase method which will remove the base from a pathname. This is useful to look up files for static assets.

  • #5292 97e2b6ad7 Thanks @MontelAle! - Changes slow astro cli imports to dynamic

  • #5293 4af4d8fa0 Thanks @matthewp! - Prevent overcaching .astro HMR changes

  • #5314 f6add3924 Thanks @matthewp! - Fixes regression with config file restarts

  • #5298 247eb7411 Thanks @wulinsheng123! - have not founded style when srcDir was root

1.6.3

Patch Changes

  • #5273 c7b9b14a1 Thanks @matthewp! - Surface astro.config errors to the user

  • #5264 0d27c4a2b Thanks @VladCuciureanu! - Fixed memleak caused by project dir names containing '.md' or '.mdx'

  • #5258 74759cf78 Thanks @bluwy! - Allow 200 response for endpoints in build

  • #5284 126cd8e83 Thanks @herteleo! - Include missing class:list within HTMLAttributes type

  • #5236 1cc067052 Thanks @bluwy! - Refactor CSS preprocessing handling

  • #5198 c77a6cbe3 Thanks @matthewp! - HMR - Improved error recovery

    This improves error recovery for HMR. Now when the dev server finds itself in an error state (because a route contained an error), it will recover from that state and refresh the page when the user has corrected the mistake.

1.6.2

Patch Changes

1.6.1

Patch Changes

1.6.0

Minor Changes

  • #5147 0bf0758fb Thanks @natemoo-re! - Add astro/types entrypoint. These utilities can be used for common prop type patterns.

    HTMLAttributes

    If you would like to extend valid HTML attributes for a given HTML element, you may use the provided HTMLAttributes type—it accepts an element name and returns the valid HTML attributes for that element name.

    import { HTMLAttributes } from 'astro/types';
interface Props extends HTMLAttributes<'a'> {
  myProp?: string;
}

  • #5164 4a8a346ca Thanks @MoustaphaDev! - Add support for markdown files with the following extensions:

    • .markdown
    • .mdown
    • .mkdn
    • .mkd
    • .mdwn

  • #4917 ddf2f8390 Thanks @natemoo-re! - Add support for --base CLI argument, which will override the base set in your astro.config.mjs file.

    astro --site https://astro.build --base /docs

Patch Changes

1.5.3

Patch Changes

  • #5133 1c477dd8d Thanks @bluwy! - Fix .css?raw usage

  • #5133 1c477dd8d Thanks @bluwy! - Update @astrojs/compiler and use the new resolvePath option. This allows removing much of the runtime code, which should improve rendering performance for Astro and MDX pages.

  • #5192 8728ee0b9 Thanks @tony-sull! - astro add no longer automatically installs optional peer dependencies

1.5.2

Patch Changes

1.5.1

Patch Changes

1.5.0

Minor Changes

  • #5056 e55af8a23 Thanks @matthewp! - # Adapter support for astro preview

    Adapters are now about to support the astro preview command via a new integration option. The Node.js adapter @astrojs/node is the first of the built-in adapters to gain support for this. What this means is that if you are using @astrojs/node you can new preview your SSR app by running:

    Adapter API

    We will be updating the other first party Astro adapters to support preview over time. Adapters can opt-in to this feature by providing the previewEntrypoint via the setAdapter function in astro:config:done hook. The Node.js adapter's code looks like this:

    export default function() {
  return {
		name: '@astrojs/node',
		hooks: {
			'astro:config:done': ({ setAdapter, config }) => {
        setAdapter({
          name: '@astrojs/node',
          serverEntrypoint: '@astrojs/node/server.js',
+          previewEntrypoint: '@astrojs/node/preview.js',
          exports: ['handler'],
        });

        // more here
      }
    }
  };
}

    The previewEntrypoint is a module in the adapter's package that is a Node.js script. This script is run when astro preview is run and is charged with starting up the built server. See the Node.js implementation in @astrojs/node to see how that is implemented.

  • #4986 ebd364e39 Thanks @bluwy! - ## New properties for API routes

    In API routes, you can now get the site, generator, url, clientAddress, props, and redirect fields on the APIContext, which is the first parameter passed to an API route. This was done to make the APIContext more closely align with the Astro global in .astro pages.

    For example, here's how you might use the clientAddress, which is the user's IP address, to selectively allow users.

    export function post({ clientAddress, request, redirect }) {
  if (!allowList.has(clientAddress)) {
    return redirect('/not-allowed');
  }
}

    Check out the docs for more information on the newly available fields: https://docs.astro.build/en/core-concepts/endpoints/#server-endpoints-api-routes

  • #4959 0ea6187f9 Thanks @Princesseuh! - Added support for updating TypeScript settings automatically when using astro add

    The astro add command will now automatically update your tsconfig.json with the proper TypeScript settings needed for the chosen frameworks.

    For instance, typing astro add solid will update your tsconfig.json with the following settings, per Solid's TypeScript guide:

    {
  "compilerOptions": {
    "jsx": "preserve",
    "jsxImportSource": "solid-js"
  }
}

  • #4947 a5e3ecc80 Thanks @JuanM04! - - Added isRestart and addWatchFile to integration step isRestart.

    • Restart dev server automatically when tsconfig changes.

  • #4986 ebd364e39 Thanks @bluwy! - ## Support passing a custom status code for Astro.redirect

    New in this minor is the ability to pass a status code to Astro.redirect. By default it uses 302 but now you can pass another code as the second argument:

    ---
// This page was moved
return Astro.redirect('/posts/new-post-name', 301);
---

  • #5056 e55af8a23 Thanks @matthewp! - # New build configuration

    The ability to customize SSR build configuration more granularly is now available in Astro. You can now customize the output folder for server (the server code for SSR), client (your client-side JavaScript and assets), and serverEntry (the name of the entrypoint server module). Here are the defaults:

    import { defineConfig } from 'astro/config';

export default defineConfig({
  output: 'server',
  build: {
    server: './dist/server/',
    client: './dist/client/',
    serverEntry: 'entry.mjs',
  },
});

    These new configuration options are only supported in SSR mode and are ignored when building to SSG (a static site).

    Integration hook change

    The integration hook astro:build:start includes a param buildConfig which includes all of these same options. You can continue to use this param in Astro 1.x, but it is deprecated in favor of the new build.config options. All of the built-in adapters have been updated to the new format. If you have an integration that depends on this param we suggest upgrading to do this instead:

    export default function myIntegration() {
  return {
    name: 'my-integration',
    hooks: {
      'astro:config:setup': ({ updateConfig }) => {
        updateConfig({
          build: {
            server: '...',
          },
        });
      },
    },
  };
}

Patch Changes

  • #5057 baf88ee9e Thanks @bluwy! - Skip JSX tagging for export statements with source

  • #5044 44ea0c6d9 Thanks @JuanM04! - Upgrade Astro compiler to 0.27.1

  • #5059 f7fcdfe62 Thanks @bluwy! - Support strict dependency install for libraries with JSX

  • #5047 1e2799243 Thanks @matthewp! - Update Astro.cookies.set types to allow booleans and numbers

    Note that booleans and numbers were already allowed, they just were not allowed by the type definitions.

1.4.7

Patch Changes

  • #5035 d7bfb144b Thanks @AirBorne04! - preventing multiple doctype injection into html documents

  • #5015 b1964e9e1 Thanks @matthewp! - Shared state in Preact components with signals

    This makes it possible to share client state between Preact islands via signals.

    For example, you can create a signals in an Astro component and then pass it to multiple islands:

    ---
// Component Imports
import Counter from '../components/Counter';
import { signal } from '@preact/signals';
const count = signal(0);
---

<Count count={count} />
<Count count={count} />

  • #5036 38fdb4ca6 Thanks @matthewp! - New algorithm for shorter CSS bundle names

1.4.6

Patch Changes

1.4.5

Patch Changes

1.4.4

Patch Changes

  • #4967 e6a881081 Thanks @matthewp! - Final perf fix from 1.3.0 regression

    A regression in rendering perf happened in 1.3.0. This is the final fix for the underlying issue.

1.4.3

Patch Changes

1.4.2

Patch Changes

1.4.1

Patch Changes

1.4.0

Minor Changes

  • #4907 01c1aaa00 Thanks @matthewp! - Order Astro styles last, to override imported styles

    This fixes CSS ordering so that imported styles are placed higher than page/component level styles. This means that if you do:

    ---
import '../styles/global.css';
---

<style>
  body {
    background: limegreen;
  }
</style>

    The <style> defined in this component will be placed below the imported CSS. When compiled for production this will result in something like this:

    /* /src/styles/global.css */
body {
  background: blue;
}

/* /src/pages/index.astro */
body:where(.astro-12345) {
  background: limegreen;
}

    Given Astro's 0-specificity hashing, this change effectively makes it so that Astro styles "win" when they have the same specificity as global styles.

  • #4876 d3091f89e Thanks @matthewp! - Adds the Astro.cookies API

    Astro.cookies is a new API for manipulating cookies in Astro components and API routes.

    In Astro components, the new Astro.cookies object is a map-like object that allows you to get, set, delete, and check for a cookie's existence (has):

    ---
type Prefs = {
  darkMode: boolean;
};

Astro.cookies.set<Prefs>(
  'prefs',
  { darkMode: true },
  {
    expires: '1 month',
  }
);

const prefs = Astro.cookies.get<Prefs>('prefs').json();
---

<body data-theme={prefs.darkMode ? 'dark' : 'light'}></body>

    Once you've set a cookie with Astro.cookies it will automatically be included in the outgoing response.

    This API is also available with the same functionality in API routes:

    export function post({ cookies }) {
  cookies.set('loggedIn', false);

  return new Response(null, {
    status: 302,
    headers: {
      Location: '/login',
    },
  });
}

    See the RFC to learn more.

Patch Changes

1.3.1

Patch Changes

1.3.0

Minor Changes

  • #4775 b0cc93996 Thanks @tony-sull! - Adds a new "astro:build:generated" hook that runs after SSG builds finish but before build artifacts are cleaned up. This is a very specific use case, "astro:build:done" is probably what you're looking for.

  • #4669 a961aa3c2 Thanks @aggre! - astro-island now correctly passes Uint8Array/Uint16Array/Uint32Array

  • #4832 73f215df7 Thanks @matthewp! - Allows Responses to be passed to set:html

    This expands the abilities of set:html to ultimate service this use-case:

    <div set:html={fetch('/legacy-post.html')} />

    This means you can take a legacy app that has been statically generated to HTML and directly consume that HTML within your templates. As is always the case with set:html, this should only be used on trusted content.

    To make this possible, you can also pass several other types into set:html now:

    • Response objects, since that is what fetch() returns: 
      <div
  set:html={new Response('<span>Hello world</span>', {
    headers: { 'content-type': 'text/html' },
  })}
/>
    • ReadableStreams: 
      <div
  set:html={new ReadableStream({
    start(controller) {
      controller.enqueue(`<span>read me</span>`);
      controller.close();
    },
  })}
/>
    • AsyncIterables: 
      <div
  set:html={(async function* () {
    for await (const num of [1, 2, 3, 4, 5]) {
      yield `<li>${num}</li>`;
    }
  })()}
/>
    • Iterables (non-async): 
      <div
  set:html={(function* () {
    for (const num of [1, 2, 3, 4, 5]) {
      yield `<li>${num}</li>`;
    }
  })()}
/>

Patch Changes

1.2.8

Patch Changes

1.2.7

Patch Changes

1.2.6

Patch Changes

1.2.5

Patch Changes

1.2.4

Patch Changes

1.2.3

Patch Changes

1.2.2

Patch Changes

1.2.1

Patch Changes

1.2.0

Minor Changes

  • #4682 d1e695914 Thanks @bholmesdev! - astro add - move configuration updates to final step

  • #4549 255636cc7 Thanks @altano! - Allow specifying custom encoding when using a non-html route. Only option before was 'utf-8' and now that is just the default.

  • #4578 c706d845e Thanks @bholmesdev! - Restart dev server when config file is added, updated, or removed

Patch Changes

1.1.8

Patch Changes

1.1.7

Patch Changes

1.1.6

Patch Changes

1.1.5

Patch Changes

1.1.4

Patch Changes

1.1.3

Patch Changes

  • #4574 b92c24f40 Thanks @delucis! - Update astro add to list official integrations & adapters with same organisation we use in docs

1.1.2

Patch Changes

1.1.1

Patch Changes

1.1.0

Minor Changes

  • #4423 d4cd7a59f Thanks @bholmesdev! - Update Markdown type signature to match new markdown plugin,and update top-level layout props for better alignment

Patch Changes

  • #4497 78e06c8ec Thanks @bholmesdev! - Production build logging - Only log [code].html instead of [code]/index.html for 404 and 500 routes

  • Updated dependencies [ac0321824, 839097c84]:

    • @astrojs/markdown-remark@1.1.0

1.1.0-next.0

Minor Changes

  • #4423 d4cd7a59f Thanks @bholmesdev! - Update Markdown type signature to match new markdown plugin,and update top-level layout props for better alignment

Patch Changes

1.0.9

Patch Changes

1.0.8

Patch Changes

  • #4385 8164fa6f1 Thanks @krolebord! - Fix warning when using hooks inside the react components not exported as a function declaration

  • #4446 27ac6a03a Thanks @matthewp! - Deterministic CSS ordering

    This makes our CSS link order deterministic. It uses CSS depth; that is how deeply a module import the CSS comes from, in order to determine which CSS is page-level vs. component-level CSS.

    This is intended to match dev ordering where, because we do not bundle, the page-level CSS always comes after component-level.

1.0.7

Patch Changes

1.0.6

Patch Changes

1.0.5

Patch Changes

  • #4302 1d3a0a16f Thanks @FredKSchott! - Revert "Ensure hydration scripts inside of slots render ASAP (#4288)" to fix Svelte integration bug

1.0.4

Patch Changes

  • #4268 f7afdb889 Thanks @bholmesdev! - Align MD with MDX on layout props and "glob" import results:
    • Add Content to MDX
    • Add file and url to MDX frontmatter (layout import only)
    • Update glob types to reflect differences (lack of rawContent and compiledContent)

1.0.3

Patch Changes

1.0.2

Patch Changes

1.0.1

Patch Changes

1.0.0

Astro v1.0 is out! Read the official announcement post.

Note If you need help migrating an existing Astro project to the new Astro v1.0, check out our updated Migration Guide and full documentation website.

0.X

For older changelog entries -- including all v0.X, v1.0 Beta, and v1.0 Release Candidate versions -- check out the v0.X changelog.