Workspace Design

Key takeaways

• Workspace design is the daily map for developers; good structure cuts onboarding time, prevents accidental coupling, and helps automation understand what changed.
• A suggested layout separates apps/, packages/, tooling/ or scripts/, docs/, and a CI directory by role.
• Name apps by product or runtime responsibility and packages by capability, avoiding generic names like common, shared, or utils unless scope is very clear.
• Review workspaces for discoverability, predictable dependency direction, clear ownership, affected-only build scope, and documented local commands.
• Treat structural changes as architecture changes, since moving a package or renaming an app affects CI, imports, ownership, and developer habits.

Workspace design is the map developers use every day. Good structure reduces onboarding time, prevents accidental coupling, and helps automation understand what changed.

Suggested Layout

Naming Rules

• App names should describe product or runtime responsibility.
• Package names should describe capability, not implementation detail.
• Avoid generic names such as common, shared, or utils unless scope is very clear.
• Use consistent package prefixes for internal ownership and publishing policy.
• Keep route names, package names, and dashboard names aligned where possible.

Workspace Review

Change Policy

Structural changes should be reviewed as architecture changes. Moving a package, renaming an app, or changing dependency direction affects CI, imports, ownership, and developer habits.