Frontend end UI Library using multiple repos for multiple clients

Question

I've just inherited a HTML/CSS based internal UI library, which the place I work is planning to use to standardize CSS styles for all of its products across the board, mainly webapps. The library has code that is in a style similar to bootstrap, however there are also separate css files for each of our clients inside that same git repo.

Now I feel that doing it this way is bad because, firstly I feel client specific styles should be in its own repository, away from the UI library's base code. Furthermore, when it comes to building the minified CSS and JavaScript for production, there is an automated build job, that bumps up the version numbers on completion. Because we have teams working with different clients at once the build jobs/releases will contain code that is 'Ready to release' for one client, but the rest will have code the is 'In Progress'. It also affects the version numbering system where were have dozens of versions, but the main base code has not changed very much.

I feel that this must be fixed, however I know that the time required to invest in this endeavor will have to be a lot; so, I thought if I can weigh up the pros and cons as well as red flags, it would be a good way to make a decision.

Currently I have in mind, is the consider separating any client-specific HTML/CSS from the current base code into separate repository, per client, per product. This repository would then import the base UI library to get the styles related to each component.

Would this be the sort of approach I am looking for for solving my above problem? Are there any possible red flags to this approach?

Answer 1

Yes you are on the right track. Most important advantage is that you can load a specific version of the library for each client. That way you can control the updates and the client specific repo will always show the real situation for that client.

Basically you can see the library just as an external library.

So to give a specific example on who it would work out:

Library

• V1.0 - Stable release
• V1.1 - Added new component in green
• V1.2 - Changed new component to red

Client repo 1

• V0.1 - Uses V1.1 so it shows a green component (in between time here the component in the library changed to red but it would NOT impact your client)
• V0.2 - You decide to upgrade library to V1.2 so now your component becomes red.

That's the main advantage, you, as developer of the client repo, are in control.

This also works better with testing. Because an upgrade in the main library might break the client project but you would not be aware of it.

In practical daily use

Be aware that you are changing the workflow of your organization. That is fine but do it with care and more importantly communication.

This change will be changing the daily routine quite a lot. Also it requires some knowledge on how to use versions and load a specific one.

Another potential disadvantage might be that a new library version is not automatically pushed to all clients. You might even consider a simple upgrade-lib command line command so it's easy for developers to upgrade to the latest version on their local machine quickly.