Wanting to know if anyone has a successful strategy for making updates to components in a library and then testing them to avoid breaking designs using those components? Example: Button components - updating elements inside button, publishing and the entire team loses any button label override, how do you avoid or test for that?
I have noticed breakage on library components after only very minor design changes when published in regards to overrides resetting.
Or is there any good documentation around what does and doesn’t break a component?
This is not the solution, but it’s how we do stuff at my company and so far it worked :
When we want to create/edit a component of our design system. We open a new branch and start working on this component in this new branch.
As it’s done, we asked each other to review it, in order to make sure it’s release proof (kinda QA test : resizing it, overflowing the text, …)
Once reviewed we publish the component (only for our Figma team) and then we jump into a test file that have all component in it, with variations, on some mock-up situation so when we update a component we can see if its change actually break our design or not.
If it breaks, go back to step 1, if not we release it to everyone
I’m afraid there is no such things as the documentation your mentioned.
Thanks @Haroll appreciate the tips. I also watched this video and tried out that process on some component updates today, it worked and I was able to switch the library to test out a couple large use components to make sure there was no breakage prior to merging the branch and republishing from the main library.
