You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Advice on Folder Structure for Angular Monorepo using NX
Hello! I've been struggling with implementing an intuitive and effective folder structure for our Angular monorepo using NX. Despite multiple iterations, I frequently find myself hitting a wall or needing to restructure due to complexities and challenges in maintaining clarity and flexibility.
Now, I feel like I've arrived at a structure that somewhat aligns logically with our business domains and feature requirements. However, I'm concerned it might be unconventional or problematic in practice. After working with it for a while, I'm again encountering difficulties.
Current Structure:
Our monorepo currently includes four distinct apps:
apps/
├── app-x
├── app-y
├── app-c
└── app-b
We organize our libs around business entities, each potentially shared across multiple apps, for example:
libs/
├── orders
│ ├── features
│ │ ├── create
│ │ ├── plan
│ │ └── details
│ ├── ui
│ └── data-access
├── containers
│ ├── features
│ │ ├── intake
│ │ ├── outload
│ │ └── search
│ ├── ui
│ └── data-access
└── shared
├── ui
├── core
│ └── auth
└── api (clients providing methods based on API specs)
This structure has felt intuitive and works reasonably well.
Issue: Where to Place Pages?
Each of our apps is essentially under the same umbrella of the product, but different production lines. Where usually each app have multiple different pages that are workstations. And a workstation might require both orders and containers to complete the entire workflow.
Initially, I tried placing pages under app-specific libs:
Duplication occurred when another app (e.g., app-y) needed similar container features.
Reduced transparency and increased complexity in dependencies, negatively impacting team collaboration.
I also considered placing pages directly within each app, but this seemed counterintuitive since it would limit visibility in NX dependency graphs—a crucial part of our documentation strategy.
Questions:
Is my current structure logical and practical? Or have I diverged significantly from NX best practices?
Where should pages logically reside? Should they be treated as libs themselves, or placed directly within apps despite losing NX dependency graph visibility?
Any insights, recommendations, or examples from your experience would be greatly appreciated.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Advice on Folder Structure for Angular Monorepo using NX
Hello! I've been struggling with implementing an intuitive and effective folder structure for our Angular monorepo using NX. Despite multiple iterations, I frequently find myself hitting a wall or needing to restructure due to complexities and challenges in maintaining clarity and flexibility.
Now, I feel like I've arrived at a structure that somewhat aligns logically with our business domains and feature requirements. However, I'm concerned it might be unconventional or problematic in practice. After working with it for a while, I'm again encountering difficulties.
Current Structure:
Our monorepo currently includes four distinct apps:
We organize our libs around business entities, each potentially shared across multiple apps, for example:
This structure has felt intuitive and works reasonably well.
Issue: Where to Place Pages?
Each of our apps is essentially under the same umbrella of the product, but different production lines. Where usually each app have multiple different pages that are workstations. And a workstation might require both orders and containers to complete the entire workflow.
Initially, I tried placing pages under app-specific libs:
However, this quickly became problematic:
app-y
) needed similar container features.I also considered placing pages directly within each app, but this seemed counterintuitive since it would limit visibility in NX dependency graphs—a crucial part of our documentation strategy.
Questions:
Any insights, recommendations, or examples from your experience would be greatly appreciated.
Beta Was this translation helpful? Give feedback.
All reactions