Astro 5 Glob Loader Bug in Monorepos
Your Astro build passed. Zero errors. Zero warnings. But your content is missing.
I recently faced this issue in a pnpm monorepo. I was using Astro 5 content collections to add editorial takes to my pages. Locally, everything worked perfectly. In my CI pipeline, the pages rendered with empty content.
The problem is how the glob loader resolves paths.
The Issue The Astro glob loader resolves relative base paths from process.cwd(). It does not use the location of your config file.
In a monorepo, your CI often runs the build from the workspace root. Locally, you probably run the build from the app directory.
- Local: cwd is apps/oss-alternatives. Path ./content works.
- CI: cwd is repository root. Path ./content does not exist.
Astro does not throw an error when it finds no files. It simply returns an empty collection. You ship a site with missing data and never know it.
The Fix Stop using relative strings for paths. Use import.meta.url to anchor your paths to the config file instead of the working directory.
Use this pattern:
import { fileURLToPath } from "node:url";
const TAKES_DIR = fileURLToPath( new URL("./content/per-alternative-takes", import.meta.url) );
This ensures the path is always correct, no matter where you run the build from.
Avoid ID Collisions The glob loader uses the slug field in your frontmatter as the ID by default. If a user adds a slug field, it can break your data lookups. Use generateId to force the filename to be the authoritative ID.
Lessons for Monorepo Developers
- Run smoke tests from the workspace root locally. If you only test from the app folder, you will miss path bugs.
- Add collection health checks. In your dev environment, throw an error if a critical collection returns zero items.
- Use absolute path resolution for every file reference in your config files.
- Add a post-deploy check to verify that key content exists in the live HTML.
Never trust silence. A successful build does not always mean a successful deployment.