The Four Dots Disaster: How `../../../../` Nearly Killed Our Monorepo
The Symptoms
For weeks, our Docker builds were a nightmare:
- ✅ Local builds: Perfect
- ❌ Hecate server: Mysterious failures
- ❌ GitHub Actions: Random crashes
- ❌ Fresh clones: Consistent breakage
The error was always the same: dist directories missing, library dependencies not found, Nx claiming projects didn't exist that clearly existed.
The Red Herrings
We chased every possible cause:
- pnpm missing on Hecate → Installed it
- Docker cache corruption → Cleared 27.91GB of cache
- docker-compose v1 conflicts → Removed legacy version
- Nx cache issues → Reset multiple times
- Missing node_modules → Reinstalled everything
Nothing worked. Fresh installations failed 100% of the time.
The Breakthrough
The hero moment came when examining a simple project.json file:
{
"name": "kaido-types",
"$schema": "../../../../node_modules/nx/schemas/project-schema.json"
}
Four dots. Four fucking dots.
From libs/core/kaido-types/project.json, this path resolves to:
../→libs/core/../→libs/../→ repo root ✅ Should stop here!../→ user home directory ❌ DISASTER
The Revelation
Every single libs/**/project.jsonfile had this bug. Nx was trying to validate schemas from~/node_modules/nx/schemas/instead of./node_modules/nx/schemas/.
When schema validation fails, Nx can't:
- Parse build configurations correctly
- Resolve output paths for
distdirectories - Generate proper dependency graphs
- Cache build artifacts reliably
The Fix
One sed command to rule them all:
find libs -name "project.json" -exec sed -i 's|\.\./\.\./\.\./\.\./node_modules|\.\./\.\./\.\./node_modules|g' {} \;
Result: Every build system immediately started working.
The Aftermath
- ✅ GitHub Actions: Green builds
- ✅ Docker on Hecate: Clean builds
- ✅ Tilt development: Smooth operation
- ✅ Fresh clones: Work out of the box
The Lesson
Sometimes the smallest typos cause the biggest disasters. Four dots vs three dots. One character difference that broke an entire build pipeline for weeks.
The real hero: The developer who refused to accept "it works locally" and kept digging until finding the root cause in a simple path resolution.
The Moral
Trust your instincts. When fresh installations consistently fail but local development works, there's always a fundamental configuration bug hiding in plain sight.
Never again, ../../../../. Never again.
