Just recently I had to write a feature for a library and its CLI to make sure that it doesn't generate files in a Git repository with unstaged changes, into a directory, that is not in .gitignore file. I implemented it and felt triggered to write my first post...but why torturing you with my writing skills?
- I could not find any blog post on the topic of using Git in JavaScript, and because I like to learn from posts, I hope others will see this post useful
- To pay respect to Steve King that is a creator of git-js library that I used in my feature
- I wanted to highlight the basic criteria for selecting an open-source library
Recently I joined AsyncAPI community to become its maintainer and work on building its community on a large scale. Why? Cause it's an awesome project, period. For me, it meant: I'm back into programming after a long damn 4/5 years. I was sure that the start will be like a ride on a bike with rusty gears and chain, but hell with it, keep on rollin' baby! feeling like a junior gives power!
Picking the right open-source project
Open-source is full of great work, though not all of it should be used in a serious project. I'm not gonna list here all the criteria you should consider to validate before choosing an open-source project. I think there were many articles written about this subject. I will focus here only on the most important criteria I took into account before choosing git-js.
Find candidates for validation
I tried to find some blog posts about the topic of using Git in JavaScript and what tools people chose and why. Learn from other's mistakes, not yours they say. I tried. I failed.
Then I looked through GitHub on my own and picked some candidates for verification. I found three candidates:
- https://github.com/steveukx/git-js
- https://github.com/creationix/js-git
- https://github.com/isomorphic-git/isomorphic-git
Verification phase
I did not verify a project that I would use as a platform for microservices, it was not a battle between Kubernetes and Cloud Foundry. I was definitely not choosing a library that will be critical for the project. A git-related feature that I had to write was pretty basic with no perspectives for future improvements and additional options.
I think you already know what I'm trying to say here.
Your verification should be as much detailed as strategic the project that you choose for your software is.
Grammarly did not complain this sentence is super bad π but maybe its time to upgrade my subscription π€
I choose git-js (on NPM called simple-git) because of the following reasons:
- It has a very good amount of stars. Yeah, I know competition had more. Still over 1.5k is good, it is really good. Is it an important factor? Does it mean the library has many users? Hell no. It is still the first thing you see on the repository though and it motivates to continue the validation, as simple as that. It is like seeing Fiat Multipla and saying damn, awesome from the outside, I need to check it from the inside π. Yeah, I know, it is a super bad reverse example, but I could not resist π
- It's used in bazillion of projects, over 41k with 1.4m weekly npm downloads. You can clearly notice that GitHub stars are less important as deeper you go in your verification. The
isomorphic-githas much more GitHub stars, but much smaller adoption. I still believe that starts important though. If you do not agree, read 1st point again. - It's not an abandoned project. It is feature-rich and started many years ago, so I did not expect extremely active development. I was positively impressed that it is still being regularly released.
- It has a good README.md with the whole API in one place, easily accessible. I could quickly verify if it has all I need. Docs always matter!
- The API is very clear, that's it. It is clear and exposes what I need.
- Even though written a long time ago, it supports my beloved async/await β€οΈ Yeah, I know it is standard now, but I feel special love to it, from times when you could use it only thanks to Babel.js...it's part of a long story about great microservice called Yoda, a story for another blog post π
There is one more reason for choosing git-js over others. It simply had features that others didn't. It supports check-ignore and rev-parse and I needed them a lot. If I'm wrong and other libs have those features, It just proofs points 4 and 5 from the above list.
Now you should get confused
Was git-js a good choice? Hell yeah, for my use case. I would reconsider my choice for different use cases though. Why?
It always depends. The same questions get always a different answer in different contexts. What if...
What if Git support would be a strategic part of the project I contributed to?
What if I would need it more than for my simple use case?
What if I would have to use it in a commercial product?
I would probably choose isomorphic-git...π
Because in more complicated cases you need to look at other things. The thing is that isomorphic-git:
- Has a sponsorship setup and visible support on Open Collective. It feels the project has better perspectives for the future. You see real users and companies that rely on it.
- It is actively developed
- It transparently shows that licenses of its dependencies are good to use in your project
It simply has better and more secure perspectives for the future. I would not ignore it.
Using git-js
First I thought I will write this blog post more focused on coding. Then I decided otherwise. I decided that it is better to share a link to my CodeSandbox where I played with some features of git-js. You can easily fork the sandbox and modify it as you wish. I think it is a nice way to kick off with the project and see for yourself how easy it is to use it. Code is not perfect, but good enough to understand it to modify and play.
Conclusion
When you choose an open-source project, choose wisely and don't follow blindly all guides (including this one) about it but map them with your context.
Respect others' work. Pay tribute in any possible way.
My personal conclusion:
- Writing is hard and takes time...
- Writing makes you think more about the subject.
Top comments (0)