How to change and manage angularjs components for different projects

Question

This is a more curious question than a technical one. In my company, we have MVP with many angularjs components, but now we offer MVP to various companies with special needs.

Here's what it will look like in real life:

Company 1

• Module 1
• Module 2
• Module 3

Company 2

• Module 1 (with a specific function or change)
• Module 3

Company 3

• Module 2
• Module 3
• Module 4 (only for this project)

And we were looking for a version system that could fit into our future business model, because, as we say, we use branches for different companies and other branches for specific components.

You can see, damn it, it has become. This is very difficult to maintain, and even more difficult to deploy different versions of the application.

I would be happy to share my conclusions if we come up with a solution for this case. I will write a blog post if this happens.

Thanks!

Answer 1

Are you looking for management of process guidance or tools?

In terms of tools, you can use npm with your private package service or just redirect to some private git repo. Bauer can do the same.

In the Windows space there is NuGet, in which you can place your repositories for or there services there too.

Git has support for submodules and subtrees, but I personally do not recommend them. Creating dependencies in your actual git history is difficult.

The biggest thing from the perspective of the process is probably just not breaking the changes. Put the effort into developing common components in the front, so you don’t have to redesign everything around the common component when it changes a lot, because it does not work correctly the way it was created the first time.

View your common modules as if they were open source projects. Keep good documentation, clean code, and stick to semantic versioning. Apply version numbers to stable lines (git tag them so they are easy to check). Put someone who is responsible for making changes to the component so that they can track what everyone else is doing to it and guide it towards development.

Add this to a new package of requirements that one project is different from others. Maintaining a component with too many different requirements can be a nightmare.