How to version and manage angularjs components for different projects

Question

This is more of a curious question than a technical one. In my company we have an MVP with lots of angularjs components, but now, we are offering the MVP to different companies with specific needs.

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

Company 1

• Module 1
• Module 2
• Module 3

Company 2

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

Company 3

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

And we were looking for a versionning system that could fit in our future business model, because as we speak, we are using branches for different companies and other branches for specific component features.

You can see the hell this has become. It's really hard to maintain and it's even harder to deploy the different versions of the application.

I'll be glad to share my findings if we come up with a solution for this case. I'll write a blog post if that's the case.

Thanks!

Answer 1

Are you looking for management of process guidance, or tools?

From a tools standpoint you could use npm, with their private package service or just directed at some private git repo. Bower can do the same.

In the Windows space there's NuGet which you can host your repositories for or there's services out there for that, too.

Git has support for submodules and subtrees, but I don't personally recommend them. Making dependencies part of your actual git history is complicated.

The biggest thing from a process perspective is probably just avoid breaking changes. Put the effort into design of shared components up front so you're not having to redesign everything around the shared component when it changes drastically because it didn't work right the way it was built the first time around.

Treat your shared modules as if they're open source projects. Keep good documentation, clean code, and adhere to semantic versioning. Apply version numbers to stable builds (git tag them so they're easy to check out). Put someone in charge of accepting changes to the component so they can keep track of what everyone else is doing with it and guide it's development.

Fork it into a new package of the requirements one project has is wildly different than the others. Maintaining a component with too many different requirements can become a nightmare.