Lampo: Building an in-house component library
Introduction
Throughout this article I will tell the story of the creation of our component library from a development point of view.
I have to start by saying that the idea and concept was born from the design team. They were the ones who detected the need to create a design system to support all of the projects that were starting to be created at that time with The Hotels Network (THN).
The company was at a point when the main product was going to be remade and other projects were still in early stages of development.
This, together with the approach that had already been taken by the design team, created the ideal conditions to think about using a library of components.
Vuetify or not Vuetify
Once it was clear that we needed to have a component library that would be used by all THN products, the question was: Do we make our own or use a third-party library?
To make this decision, we did what is always done for big decisions. A list of pros and cons of each alternative:
Third-party library:
- Speed: with a third-party library you can work from day 0.
- Maintainability: these libraries have a team behind them that is in charge of their evolution and bug fixes.
- Community: they have a community of users who are responsible for detecting errors and providing new solutions.
Own library:
- Control: developing on your own gives total control over the technical stack used and over the functionalities that each of your components must have.
- Customization: at a graphic level, developing your own system of components allows you to fine-tune every last detail.
- Learning: making a component knowing that it must work, not only in your project but in all the company’s projects, makes you see the development of components in a much more “SOLID” way. And you can apply this learning to the rest of your developments.
The decision to make our own component system wasn’t based on one single reason, but I think the learning part was what tipped the balance.
We have learned a lot by developing this library.
Definition of the library
The first step in the creation of our library was thinking about what form it would take so that it would be accessible for all projects.
At the technical stack level we opted for Vue3 + Tailwind as it is the stack used in all of the company’s products.
We also decided to publish it as a private package in NPM in order to keep version control and make it easily accessible for all projects.
Finally, we defined a style guide when contributing to the library:
- The components had to follow the look & feel set by the design team.
- The components could not be tied to any specific project.
- Components should be as versatile as possible. They should be configurable by the project that consumes them and whenever possible, the use of slots should be prioritized over props.
- All components and their utilities should be properly tested and have a coverage of more than 90%.
- The components should be documented. For this purpose, we installed Storybook in the project. Each component has its documentation attached in this platform, as well as a live example of the most common uses.
Organizing the work
The first challenge we faced was how to move forward with the development of the library without this project having any team assigned to it.
We decided to use an “If you need it, you do it” philosophy. The team that needed a component would be in charge of its development. In the same way, the team that detected a bug or needed to expand the functionality of one of the components would be in charge of this work.
Releasing
The release of versions is a process that has a lot of work associated with it. Deciding on the type of version, documentation in the changelog, tagging, etc. To automate all of these processes we use Semantic Release integrated in our CI/CD workflow.
This offers us:
- Recognition of version type based on analysis of commit messages since the last version.
- Tagging and releasing in our repository.
- Updating the project changelog following the commit messages.
- Publication of the package in NPM.
- Communication of the published version in our Slack channel.
Current status of the project
Since the first commit in February 2021, a further 1,275 have arrived. With a total of 96 releases. The library already has 58 components and we have expanded its use beyond what is a pure component library with the idea of approaching a design system.
It currently has a color and font guide, and defines a Tailwind preset with the company’s style guide.
