Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ci] release (beta) #12100

Merged
merged 1 commit into from
Oct 7, 2024
Merged

[ci] release (beta) #12100

merged 1 commit into from
Oct 7, 2024

Conversation

astrobot-houston
Copy link
Contributor

@astrobot-houston astrobot-houston commented Oct 1, 2024

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to next, this PR will be updated.

⚠️⚠️⚠️⚠️⚠️⚠️

next is currently in pre mode so this branch has prereleases rather than normal releases. If you want to exit prereleases, run changeset pre exit on next.

⚠️⚠️⚠️⚠️⚠️⚠️

Releases

astro@5.0.0-beta.4

Major Changes

  • #11979 423dfc1 Thanks @bluwy! - Bumps vite dependency to v6.0.0-beta.2. The version is pinned and will be updated as new Vite versions publish to prevent unhandled breaking changes. For the full list of Vite-specific changes, see its changelog.

  • #12100 abf9a89 Thanks @astrobot-houston! - Refactors legacy content and data collections to use the Content Layer API glob() loader for better performance and to support backwards compatibility. Also introduces the legacy.collections flag for projects that are unable to update to the new behavior immediately.

    ⚠️ BREAKING CHANGE FOR LEGACY CONTENT COLLECTIONS ⚠️

    By default, collections that use the old types (content or data) and do not define a loader are now implemented under the hood using the Content Layer API's built-in glob() loader, with extra backward-compatibility handling.

    In order to achieve backwards compatibility with existing content collections, the following have been implemented:

    • a glob loader collection is defined, with patterns that match the previous handling (matches src/content/<collection name>/**/*.md and other content extensions depending on installed integrations, with underscore-prefixed files and folders ignored)
    • When used in the runtime, the entries have an ID based on the filename in the same format as legacy collections
    • A slug field is added with the same format as before
    • A render() method is added to the entry, so they can be called using entry.render()
    • getEntryBySlug is supported

    In order to achieve backwards compatibility with existing data collections, the following have been implemented:

    • a glob loader collection is defined, with patterns that match the previous handling (matches src/content/<collection name>/**/*{.json,.yaml} and other data extensions, with underscore-prefixed files and folders ignored)
    • Entries have an ID that is not slugified
    • getDataEntryById is supported

    While this backwards compatibility implementation is able to emulate most of the features of legacy collections, there are some differences and limitations that may cause breaking changes to existing collections:

    • In previous versions of Astro, collections would be generated for all folders in src/content/, even if they were not defined in src/content/config.ts. This behavior is now deprecated, and collections should always be defined in src/content/config.ts. For existing collections, these can just be empty declarations (e.g. const blog = defineCollection({})) and Astro will implicitly define your legacy collection for you in a way that is compatible with the new loading behavior.
    • The special layout field is not supported in Markdown collection entries. This property is intended only for standalone page files located in src/pages/ and not likely to be in your collection entries. However, if you were using this property, you must now create dynamic routes that include your page styling.
    • Sort order of generated collections is non-deterministic and platform-dependent. This means that if you are calling getCollection(), the order in which entries are returned may be different than before. If you need a specific order, you should sort the collection entries yourself.
    • image().refine() is not supported. If you need to validate the properties of an image you will need to do this at runtime in your page or component.
    • the key argument of getEntry(collection, key) is typed as string, rather than having types for every entry.

    A new legacy configuration flag legacy.collections is added for users that want to keep their current legacy (content and data) collections behavior (available in Astro v2 - v4), or who are not yet ready to update their projects:

    // astro.config.mjs
    import { defineConfig } from 'astro/config';
    
    export default defineConfig({
      legacy: {
        collections: true,
      },
    });

    When set, no changes to your existing collections are necessary, and the restrictions on storing both new and old collections continue to exist: legacy collections (only) must continue to remain in src/content/, while new collections using a loader from the Content Layer API are forbidden in that folder.

  • #12079 7febf1f Thanks @ematipico! - params passed in getStaticPaths are no longer automatically decoded.

    [changed]: params aren't decoded anymore.

    In Astro v4.x, params in were automatically decoded using decodeURIComponent.

    Astro v5.0 doesn't automatically decode params in getStaticPaths anymore, so you'll need to manually decode them yourself if needed

    What should I do?

    If you were relying on the automatic decode, you'll need to manually decode it using decodeURI.

    Note that the use of decodeURIComponent) is discouraged for getStaticPaths because it decodes more characters than it should, for example /, ?, # and more.

    ---
    export function getStaticPaths() {
      return [
    +    { params: { id: decodeURI("%5Bpage%5D") } },
    -    { params: { id: "%5Bpage%5D" } },
      ]
    }
    
    const { id } = Astro.params;
    ---

Patch Changes

@astrojs/svelte@6.0.0-beta.1

Patch Changes

@github-actions github-actions bot added pkg: example Related to an example package (scope) pkg: astro Related to the core `astro` package (scope) labels Oct 1, 2024
@github-actions github-actions bot force-pushed the changeset-release/next branch 6 times, most recently from 7142fdc to 5298038 Compare October 4, 2024 15:11
@github-actions github-actions bot force-pushed the changeset-release/next branch 3 times, most recently from c190201 to 0b93b58 Compare October 5, 2024 10:00
@Princesseuh Princesseuh merged commit 676b2c6 into next Oct 7, 2024
@Princesseuh Princesseuh deleted the changeset-release/next branch October 7, 2024 13:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pkg: astro Related to the core `astro` package (scope) pkg: example Related to an example package (scope)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants