#1 How I started building the idea 📒

Hello there! I’m Nicolás, a front-end developer from Argentina. I’ve been in the industry since 2016, and this is the first article in a series that I decided to write after working on a personal open-source project in 2023. There’s definitely been a learning curve, and I’d like to share my experience with you on how to create a component library based on a CSS framework.

Before starting with the good tech stuff (like integrating with npm, automating version control through git commits, and structuring the component hierarchy), let’s first talk about how the project came to life from the very beginning. For that, I need to answer two key questions.

Why did I choose a component library?

It all started after completing a Typescript course at the end of 2022; at that moment, I was excited because I got a new course certificate to add to my LinkedIn and a public repo with my comments. However, I wanted to put those lessons into practice. Unfortunately, the client code at my job was too complex for a straightforward TypeScript implementation, so I decided to take on a side project. The one I found most interesting was a component library. I had worked on a few client projects before and wanted to dive deeper into how other public alternatives maintain their libraries (like Material UI, AntDesign, and Bootstrap, to name a few).

How did I begin organizing the project?

Once the objective had been set, these were the steps I followed

1. Named the library Reactive Bulma’s and created the repo.
2. Created the first issues in its repo.
3. Created a Project (a GitHub feature that works as a Jira alternative) to organize all current and future issues.
4. Looked for possible tech stacks and compared each case until finding the best fit (reference, Ticket #2)
5. Applied the same concept to third-party tools for code improvement (reference, Ticket #4).
6. Investigated all possible components to be migrated according to the stack I chose, which led to the creation of milestones and the roadmap (reference, Ticket #1).
7. Added the first folder structure and most basic libraries to the repo's first commits (reference, Ticket #5).
8. And lastly:
   • Wrote the essential documentation for the repo.
   • Established a git flow approach.
   • Created GitHub issue templates to avoid repetitive actions.
   • Added tags for issues related to specific topics (like research, bugs, documentation, or feature implementation).
   • (reference, Ticket #6)

The steps above helped me focus my work and create a structure to organize and document all the changes I would encounter, which I’ll discuss in the upcoming articles.

See you in the next episode: Pick the right tool for the right job.