Build time issues

[greenhost87]

When deploying a single app from the monorepo, the current Docker flow still behaves monorepo-wide:

1. Build stage runs root-level yarn build.
2. Runtime stage copies the full /app directory.

This makes app-level deploys expensive in build time and image size.

Current behavior

• Builder runs yarn build from repo root (Dockerfile:65).
• Runtime copies full /app from builder (Dockerfile:75).
• CI prepares ./out, but it is not app-scoped and includes workspace manifests broadly (.github/workflows/nodejs.condo.ci.yml:70, bin/prune.sh:1).

Why this is a problem

• Slower CI/CD for app-specific releases.
• Larger push/pull payloads for single-service deploys.
• Runtime image includes dependencies unrelated to the target app.
• In practice, runtime deploys may require transferring very large node_modules directories, even for a single app.

Reproduction (current state)

1. Build image from repository root.
2. Measure build duration and final image size.
3. Inspect runtime image contents and verify unrelated apps/dependencies are present.

Expected behavior

For app-level deployment (@app/<name>):

• Each sub-project can be built independently (without monorepo-wide build coupling).
• Build scope is limited to target app + required workspace dependencies only.
• Runtime image contains only required runtime artifacts/dependencies for target app.
• Runtime image does not include monorepo-wide node_modules and unrelated app sources.
• Running one app should not require shipping huge monorepo node_modules.

Request

Could maintainers advise on the recommended Condo approach for:

• app-scoped Docker builds (instead of root monorepo-wide build),
• app-scoped runtime dependency packaging,
• avoiding full /app copy into runtime for single-service deploys?

[pahaz]

Hi! 👋

Right now we build a reproducible release for all apps in the monorepo: one commit -> one set of artifacts. That gives verifiability and simple debugging. That said, nothing stops you from building and releasing each app independently - locally or in CI.

Important: we keep package versions in sync and up to date across the repo. It matters to us that dependency updates land in every app, which is why the default pipeline builds them together.

Help us understand what’s blocking you:

• do you want fully separate per‑app releases, or just faster builds?
• is the issue CI config, scripts, versions/tags, or env vars?
• do you need per‑app artifacts/containers and independent versioning?
• is there a case where the unified release breaks your flow?

From there we’ll pick the right approach: path filters, a build matrix, or dedicated jobs per package. ✨

[greenhost87]

Hi,

Our main goal is to speed up build times overall, without splitting releases or versioning by app.

• We want faster build times in general. Right now, a full build often takes more than one hour.
• We do not need independent per-app versioning.
• We don’t have a specific case where the unified release model breaks our flow.

As a result, the core issue is overall build duration.