Empty content collections with programmatic API since 5.0.3

[HiDeoo]

Astro Info

Astro                    v5.0.3
Node                     v18.20.3
System                   Linux (x64)
Package Manager          npm
Output                   static
Adapter                  none
Integrations             none

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

Spotted in a similar scenario in an E2E test in the Starlight repo, it looks like using the Astro programmatic API to build a project using content collections, serving it and then starting a dev server leads to different results:

• The served production build works as expected.
• The dev server logs that the collection does not exist or is empty.

In the linked repro, the following script is immediately run:

import { dev, build, preview } from 'astro';

const root = './';

await build({ logLevel: 'debug', root });
const prodServer = await preview({ logLevel: 'debug', root });

const devServer = await dev({ root });

The preview panel will work as expected as it's showing the production version built first and served on the port 4321.
Manually changing the URL to switch to the dev server (there is a 4321 in the URL that can be changed to 4322) will show a 404 error and log the mentioned error.

Note that this works fine when using Astro v5.0.2, maybe related to #12640 but only a guess.

What's the expected result?

The expected result is the same behavior in both cases.

Link to Minimal Reproducible Example

https://stackblitz.com/edit/github-gaqwbs?file=repro.js&on=stackblitz

Participation

• I am willing to submit a pull request for this issue.

[lilnasy]

Ran into this as well.

[lilnasy]

astro/packages/astro/src/content/content-layer.ts

Line 336 in f13417b

isDev ??= process?.env.NODE_ENV === 'development';

NODE_ENV can be testing during dev.

A quick fix would be to be explicit here as well (similar to the changes to dev() in #12640):

astro/packages/astro/src/content/content-layer.ts

Line 234 in f13417b

const cacheFile = getDataStoreFile(this.#settings);

A better fix would be derive isDev from createVite's command to remove the guesswork altogether:

astro/packages/astro/src/core/create-vite.ts

Lines 89 to 92 in f13417b

	export async function createVite(
	commandConfig: vite.InlineConfig,
	{ settings, logger, mode, command, fs = nodeFs, sync, manifest, ssrManifest }: CreateViteOptions,
	): Promise<vite.InlineConfig> {

[delucis]

Noting that @ascorbic hoped this might be a duplicate of #12866 and fixed in 5.1.4, but it unfortunately doesn’t seem to be the case. Starlight end-to-end tests which are impacted by this issue are still failing in withastro/starlight#2736 after to updating to 5.1.4