Stabilize live collections

[ascorbic]

Changes

Removes the experimental.liveContentCollections flag and enables it for all sites.

Closes #14376

Testing

Updated test fixture

Docs

Added changeset. It doesn't have any links to docs, because I'm not sure where they'll live.

EDITED BY SARAH:

• Docs PR 12587 includes the necessary content for the upgrade guide (removing the experimental live collections flag)
• Branch where I am rewriting the Content Collections guide, which will include live collections: https://github.com/withastro/docs/tree/stable-live-collections (No PR yet since I expect a bunch of draft writing going on)

@withastro/maintainers-docs

[changeset-bot]

🦋 Changeset detected

Latest commit: 6170318

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[florian-lefebvre]

Love to see such a small PR!

[sarah11918]

Looks great! And if anything gets a pass at not being a minimal changeset, it's this one! (It won't really be in the upgrade guide at all other than removing the experimental flag, so it should shine here.)

Some tiny comments below!

[yanthomasdev]

may have contained breaking changes to this experimental feature

What do we mean by "may"? We don't know if there were breaking changes to the feature? I feel like we could be clearer here.

[sarah11918]

That's fair! I think I saw an update in 5.10.2 (so you no longer specify a live type of collection) and there's a current breaking change PR we just reviewed (not sure if going out in a 5.14 patch, or will wait for 5.15.0) that for sure is a breaking change).

This is kind of generic language, because I also don't know what other breaking changes might come up between now and then. But in fact, we could just take out the words "may have" and it would be correct!

[ascorbic]

I removed the "may have". There were breaking changes in some of them.

[ascorbic]

@sarah11918 does this need anything for docs approval? It'd be good to merge it into next

[ArmandPhilippot]

The changeset looks good to me! Maybe this was waiting for a section to exist in docs to link to (ie. #14550 (comment))? But I guess we can always update the changeset later. So, it should be safe to merge I think.

Kinda related to stabilizing live collections, when checking the imports to document the astro:content module in withastro/docs#12620, I noticed the following imports:

import type {
  LiveDataCollection,
  LiveDataCollectionResult,
  LiveDataEntry,
  LiveDataEntryResult,
} from "astro";

Since we have CollectionEntry for build-time collections, it would be nice to be able to document LiveDataEntry as well, but that's problematic if it doesn't come from astro:content.

Is there a reason for those imports to be exported from astro instead of astro:content? Should this be fixed here or in another PR?

[sarah11918]

Just two thoughts left here on the changeset. (Acknowledging that the corresponding docs PR means rewriting the entire content collections guide, so will take some time! But no need to wait for that before this PR merges.)

Will also note Armand's comments that will affect documenting alongside (or not?) astro:content should also be resolved, but I'm approving the changeset, and saying we don't have to wait for all the docs on this topic to be done!

[florian-lefebvre]

What is missing to get this merged?

[ArmandPhilippot]

Sarah approved this, and I got an answer to my question from Matt in another PR:

Moving the type export to astro:content makes sense I think. I can't remember what my reason was for exporting it from the astro, but it's probably somehting that no longer exists

So, nothing blocking from docs! Ideally, some types should be moved, but that doesn't need to be done here or now!