🏈 Rugby: Remastered

22.04.2023

4 min

A lot of time has passed since the release of the first version of Rugby. Last time I struggled with indexing at all costs. This time, I was fixing fundamental problems and got a little carried away. This is how 🏈 Rugby: Remastered appeared.

For What?

Maybe you wonder why I needed to develop a new version. What’s wrong with the previous one? It has some fundamental drawbacks which make development pretty complicated. It is not only my opinion. I had some feedback from the community.

I realized that I needed to reinvent almost everything. And I did it all in one go. I thought it was better to make one major version instead of a bunch of them. But anyway, I tried to keep the known soul of Rugby and slightly embellish it.

What Makes the New Version Different?

Cache consistency

Sometimes Rugby wasn’t rebuilding modules after changes. The issue could be solved by calling command rugby clean or passing the flag --ignore-checksums. But it was not by design and led to user’s frustration. At the same time, it used to rebuild modules too often even if it was unnecessary. I challenged myself and tried to make a new better algorithm for calculating modules checksums.

Cache distribution

The previous version keeps cache in each project directory. That choice bounds Rugby development. I decided to move the projects cache to one global directory. It allows reusing all binaries between any git branch or even any project. Also, it can be used as a remote cache between different Macs, including CI runners.

W/o magic interfaces

I received a lot of questions about Rugby commands. Some of them have bad names. Names are repeated with different results. They are unclear and have unexpected magic under the hood. I read some CLT guides and tried to make everything a bit better.

Optimizations

I always do experiments in my home projects. Now I’m learning async/await API, and this fact has already changed Rugby architecture. I tried to make all things targeted to concurrency. Also, I got carried away during refactoring and reinvented some Rugby parts in favour of speed.

Remote Cache

All these changes opened the way to the implementation of remote cache. The basic command works with AWS S3, but Rugby interfaces allow you to configure uploading and downloading for any cloud storage.

This approach can seriously reduce the total building time of the entire team both on personal Macs and when launching CI/CD pipelines. However, it is worth paying attention to optimizing the download speed from the selected cloud storage.

Roadmap

What's next? I'm going to refactor some parts of the codebase. Then I will write more tests, including unit ones, which were absent in the first version. After that, I will prepare the documentation, set up the necessary pipelines and be ready for the release of the open-source version.

Conclusion

The new version of Rugby 🏈 not only struggles with indexing, but can also seriously reduce the build process time. After redesigning the interface, it has become easier to use. And some of the steps in the commands have sped up.

At the same time, the source code was rewritten to a new architecture, which in my opinion, will be more understandable to everyone. I hope that soon, I will open the source code, and it will be easier for the community to develop and support Rugby together.