Reputation: 2937
I'm trying to figure out the best way to structure a (inevitably large) but currently small angular application that my team will be working on. This will be rewrite of a large legacy system which is a nightmare to maintain.
The main goal here is to keep the project lean, easy to navigate and modify from development point of view. I am currently thinking of something like:
- src
- main app module
- core application code & ui
- feature modules
- feature 1 module
- feature 2 module
- ..
This seems to make sense, however this will inevitably get large and messy. Folder structure is bound to get deep and hard to navigate. Confusion will probably ensue.
What I am thinking of doing instead is something like:
- src
- main app module
- core application code & ui
- feature module dependencies
- feature 1 app
- feature 2 app
- ...
So each large feature will be its own angular application, which will be developed in isolation, re-using any shared/common code as modules. It can be ran and tested separately and once complete, it will be installed using
npm install https://github.com/<feature name>
into the main application. It will then be imported into the main application as a single component.
The problem that I'm having at the moment is trying to figure out:
Has anyone faced this before?
Thanks!
Upvotes: 1
Views: 102
Reputation: 35665
Is this a good idea?
If it's just you, then I recommend you keep it really simple. This has worked well for me in the past:
Stable branch / Main master branch
Feature branches (The branch upon which features are developed). When you're happy with those features then merge or rebase them back into the master branch - then you can delete the feature branch and move on to the next feature.
As far as angular apps and namespacing issues - I don't know enough to answer this.
Upvotes: 1