feat: initial live loader implementation

[ascorbic]

Changes

First draft of live loaders, implementing withastro/roadmap#1151. Merging into #13685

This implementation requires the user to define the collections in src/live-content.config.ts. It creates a new collection type called live, which takes a new type of loader called LiveLoader. This has the following signature:

export interface LiveLoader<
	TData extends Record<string, unknown> = Record<string, unknown>,
	TEntryFilter extends Record<string, unknown> | never = never,
	TCollectionFilter extends Record<string, unknown> | never = never,
> {
	/** Unique name of the loader, e.g. the npm package name */
	name: string;
	/** Load a single entry */
	loadEntry: (context: LoadEntryContext<TEntryFilter>) => Promise<LiveDataEntry<TData> | undefined>;
	/** Load a collection of entries */
	loadCollection: (
		context: LoadCollectionContext<TCollectionFilter>,
	) => Promise<LiveDataCollection<TData>>;
}

The collection is currently typed by setting a generic for LiveLoader. There isn't any schema implementation yet.

If we're happy with this approach I will propose for the RFC to go to stage 3, and will write up the full RFC.

Testing

Currently, just a fixture with manual tests.

Docs

[changeset-bot]

⚠️ No Changeset found

Latest commit: 96abe0e

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

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

[ematipico]

Some feedback:

• content.config disappears at the end of he build, but what about the live.config file? This isn't clear from the PR and the RFC.
• nit: not very fond of the live-content name, because it could be liveContent too. Maybe live.config.* works better

[ascorbic]

It's imported into the virtual module here, so it's included as a chunk in the build:

astro/packages/astro/src/content/vite-plugin-content-virtual-mod.ts

Lines 254 to 255 in ff5d8ce

	? // Dynamic import so it extracts the chunk and avoids a circular import
	`const liveCollections = (await import(${JSON.stringify(fileURLToPath(contentPaths.liveConfig.url))})).collections;`

Yeah, I'm not sure about the name either. I'm going to keep it like this for now. I may yet be able to use one file for them, which would be the ideal.

[ematipico]

Got it.

I'm going to leave a comment here based on my knowledge, however take it with a grain of salt because I don't know the future design of the feature. This isn't a blocker comment

I believe we will need a refactor of this code: the current content collections aren't optimised for SSR. When built, they generate a lookup table for all collections. We usually discourage the use of collections in SSR. Which means the live collections will need to be smarter I suppose, and won't need much of the code that is generated now by our internals. Essentially, if we have live collections and content collections, in SSR we should only have the relevant code that belong to live collections.

Also, since this configuration is a production file, very much like actions and middleware (that's what I understood), we should evaluate it's loading via vite and rollup.