Skip to content

[email protected]
Compare
Choose a tag to compare
@astrobot-houston astrobot-houston released this 11 Mar 10:27
· 1519 commits to main since this release
[email protected]
0e074fb
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.

Minor Changes

  • #10206 dc87214141e7f8406c0fdf6a7f425dad6dea6d3e Thanks @lilnasy! - Allows middleware to run when a matching page or endpoint is not found. Previously, a pages/404.astro or pages/[...catch-all].astro route had to match to allow middleware. This is now not necessary.

    When a route does not match in SSR deployments, your adapter may show a platform-specific 404 page instead of running Astro's SSR code. In these cases, you may still need to add a 404.astro or fallback route with spread params, or use a routing configuration option if your adapter provides one.

  • #9960 c081adf998d30419fed97d8fccc11340cdc512e0 Thanks @StandardGage! - Allows passing any props to the <Code /> component

  • #10102 e3f02f5fb1cf0dae3c54beb3a4af3dbf3b06abb7 Thanks @bluwy! - Adds a new experimental.directRenderScript configuration option which provides a more reliable strategy to prevent scripts from being executed in pages where they are not used.

    This replaces the experimental.optimizeHoistedScript flag introduced in v2.10.4 to prevent unused components' scripts from being included in a page unexpectedly. That experimental option no longer exists and must be removed from your configuration, whether or not you enable directRenderScript:

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

export default defineConfig({
	experimental: {
-		optimizeHoistedScript: true,
+		directRenderScript: true
	}
});

    With experimental.directRenderScript configured, scripts are now directly rendered as declared in Astro files (including existing features like TypeScript, importing node_modules, and deduplicating scripts). You can also now conditionally render scripts in your Astro file.

    However, this means scripts are no longer hoisted to the <head> and multiple scripts on a page are no longer bundled together. If you enable this option, you should check that all your <script> tags behave as expected.

    This option will be enabled by default in Astro 5.0.

  • #10130 5a9528741fa98d017b269c7e4f013058028bdc5d Thanks @bluwy! - Stabilizes markdown.shikiConfig.experimentalThemes as markdown.shikiConfig.themes. No behaviour changes are made to this option.

  • #10189 1ea0a25b94125e4f6f2ac82b42f638e22d7bdffd Thanks @peng! - Adds the option to pass an object to build.assetsPrefix. This allows for the use of multiple CDN prefixes based on the target file type.

    When passing an object to build.assetsPrefix, you must also specify a fallback domain to be used for all other file types not specified.

    Specify a file extension as the key (e.g. 'js', 'png') and the URL serving your assets of that file type as the value:

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

export default defineConfig({
  build: {
    assetsPrefix: {
      js: 'https://js.cdn.example.com',
      mjs: 'https://js.cdn.example.com', // if you have .mjs files, you must add a new entry like this
      png: 'https://images.cdn.example.com',
      fallback: 'https://generic.cdn.example.com',
    },
  },
});

  • #10252 3307cb34f17159dfd3f03144697040fcaa10e903 Thanks @Princesseuh! - Adds support for emitting warning and info notifications from dev toolbar apps.

    When using the toggle-notification event, the severity can be specified through detail.level:

    eventTarget.dispatchEvent(
  new CustomEvent('toggle-notification', {
    detail: {
      level: 'warning',
    },
  })
);

  • #10186 959ca5f9f86ef2c0a5a23080cc01c25f53d613a9 Thanks @Princesseuh! - Adds the ability to set colors on all the included UI elements for dev toolbar apps. Previously, only badge and buttons could be customized.

  • #10136 9cd84bd19b92fb43ae48809f575ee12ebd43ea8f Thanks @matthewp! - Changes the default behavior of transition:persist to update the props of persisted islands upon navigation. Also adds a new view transitions option transition:persist-props (default: false) to prevent props from updating as needed.

    Islands which have the transition:persist property to keep their state when using the <ViewTransitions /> router will now have their props updated upon navigation. This is useful in cases where the component relies on page-specific props, such as the current page title, which should update upon navigation.

    For example, the component below is set to persist across navigation. This component receives a products props and might have some internal state, such as which filters are applied:

    <ProductListing transition:persist products={products} />

    Upon navigation, this component persists, but the desired products might change, for example if you are visiting a category of products, or you are performing a search.

    Previously the props would not change on navigation, and your island would have to handle updating them externally, such as with API calls.

    With this change the props are now updated, while still preserving state.

    You can override this new default behavior on a per-component basis using transition:persist-props=true to persist both props and state during navigation:

    <ProductListing transition:persist-props="true" products={products} />

  • #9977 0204b7de37bf626e1b97175b605adbf91d885386 Thanks @OliverSpeir! - Supports adding the data-astro-rerun attribute on script tags so that they will be re-executed after view transitions

    <script is:inline data-astro-rerun>
  ...
</script>

  • #10145 65692fa7b5f4440c644c8cf3dd9bc50103d2c33b Thanks @alexanderniebuhr! - Adds experimental JSON Schema support for content collections.

    This feature will auto-generate a JSON Schema for content collections of type: 'data' which can be used as the $schema value for TypeScript-style autocompletion/hints in tools like VSCode.

    To enable this feature, add the experimental flag:

    import { defineConfig } from 'astro/config';

export default defineConfig({
	experimental: {
+		contentCollectionJsonSchema: true
	}
});

    This experimental implementation requires you to manually reference the schema in each data entry file of the collection:

    // src/content/test/entry.json
{
+  "$schema": "../../../.astro/collections/test.schema.json",
  "test": "test"
}

    Alternatively, you can set this in your VSCode json.schemas settings:

    "json.schemas": [
  {
    "fileMatch": [
      "/src/content/test/**"
    ],
    "url": "../../../.astro/collections/test.schema.json"
  }
]

    Note that this initial implementation uses a library with known issues for advanced Zod schemas, so you may wish to consult these limitations before enabling the experimental flag.

  • #10130 5a9528741fa98d017b269c7e4f013058028bdc5d Thanks @bluwy! - Migrates shikiji to shiki 1.0

  • #10268 2013e70bce16366781cc12e52823bb257fe460c0 Thanks @Princesseuh! - Adds support for page mutations to the audits in the dev toolbar. Astro will now rerun the audits whenever elements are added or deleted from the page.

  • #10217 5c7862a9fe69954f8630538ebb7212cd04b8a810 Thanks @Princesseuh! - Updates the UI for dev toolbar audits with new information

Patch Changes

Assets 2
Loading