Waleed
856fe0ffb6
* fix(docker): upgrade bun to 1.3.14 to unbreak the Next 16.3.0 server
Bun 1.3.13 cannot load Next 16.3.0's compiled server runtime. The app container
runs the Next server under Bun (`oven/bun:1.3.13-slim`, `bun apps/sim/bootstrap.js`),
so every app-page render threw and `/api/health` returned 500:
⨯ Error: Failed to load external module
next/dist/compiled/next-server/app-page-turbo.runtime.prod.js:
TypeError: Expected CommonJS module to have a function wrapper.
If you weren't messing around with Bun's internals, this is a bug in Bun
Isolated to Bun, not Next, by loading that exact module in the real images:
Next 16.2.12 + Bun 1.3.13 -> loads (why staging was fine before)
Next 16.3.0 + Bun 1.3.13 -> CJS wrapper error
Next 16.3.0 + Bun 1.3.14 -> loads
Bun 1.3.14 is the current stable and already fixes it, so this bumps every pin
rather than reverting the framework upgrade, which would only defer the same
latent Bun bug to the next attempt.
Why no gate caught it: local dev machines and this bump's own verification run
Bun 1.3.14, while the container and CI pinned 1.3.13 — and CI only *builds* the
image, it never boots one and probes `/api/health`. A container smoke test in CI
would have caught this before merge; that is worth adding separately.
* fix(docker): align the remaining bun pins with 1.3.14
Two pins were missed in the first pass because the search was scoped to
docker/, package.json and .github/workflows/:
- .devcontainer/Dockerfile still built on oven/bun:1.3.13-alpine
- PI_BUN_VERSION in apps/sim/scripts/pi-sandbox-packages.ts was still 1.3.13,
despite being documented as mirroring the root packageManager field, so Pi
sandbox images would have kept installing the Bun release that cannot load
the Next 16.3.0 server runtime.
Fixed surgically rather than with a repo-wide replace: "1.3.13" also appears
inside SVG path data in apps/sim/components/icons.tsx and
apps/docs/components/icons.tsx, which a blind sed would have corrupted.
Sim Development Container
Development container configuration for VS Code Dev Containers and GitHub Codespaces.
Prerequisites
- Visual Studio Code
- Docker Desktop or Podman Desktop
- VS Code Dev Containers extension
Getting Started
- Open this project in VS Code
- Click "Reopen in Container" when prompted (or press
F1→ "Dev Containers: Reopen in Container") - Wait for the container to build and initialize
- Start developing with
sim-start
The setup script will automatically install dependencies and run migrations.
Development Commands
Running Services
You have two options for running the development environment:
Option 1: Run everything together (recommended for most development)
sim-start # Runs both app and socket server using concurrently
Option 2: Run services separately (useful for debugging individual services)
- In the app container terminal:
sim-app(starts Next.js app on port 3000) - In the realtime container terminal:
sim-sockets(starts socket server on port 3002)
Other Commands
sim-migrate- Push schema changes to the databasesim-generate- Generate new migrationsbuild- Build the applicationpgc- Connect to PostgreSQL database
Troubleshooting
Build errors: Rebuild the container with F1 → "Dev Containers: Rebuild Container"
Port conflicts: Ensure ports 3000, 3002, and 5432 are available
Container runtime issues: Verify Docker Desktop or Podman Desktop is running
Technical Details
Services:
- App container (8GB memory limit) - Main Next.js application
- Realtime container (4GB memory limit) - Socket.io server for real-time features
- Database - PostgreSQL with pgvector extension
- Migrations - Runs automatically on container creation
You can develop with services running together or independently.
Personalization
Project commands (sim-start, sim-app, etc.) are automatically available via /workspace/.devcontainer/sim-commands.sh.
Personal shell customization (aliases, prompts, etc.) should use VS Code's dotfiles feature:
- Create a dotfiles repository (e.g.,
github.com/youruser/dotfiles) - Add your
.bashrc,.zshrc, or other configs - Configure in VS Code Settings:
{ "dotfiles.repository": "youruser/dotfiles", "dotfiles.installCommand": "install.sh" }
This separates project-specific commands from personal preferences, following VS Code best practices.