percircle is a project I started on 2015, without having a clue about js (which is still valid :-P), but of course, there’s always place for improvement.
Today I noticed that I was creating a dirty history with several small unnecessary commits, so, I thought about experimenting a bit.
Below you can see a not-so-nice history of 4 commits. What they actually are about is 2 commits for the readme file and a corresponding release to npm for each one of them. But those two changes could be displayed as one, since only the latest is the one that contains the proper changes. So, I wanna somehow erase commits f13df6d and 12632de.
For this, I will be needing the help of git rebase. Specifically, I wanna rebase on top of the latest release, prior to any changes in the readme file. That is, the commit for November 3:
git rebase -i e1a7e698d399b51cfd2cf283e0ff25d8aa23175c
I then just “drop” the commits that I don’t wanna be included in my history anymore and totally be deleted:
I save the file and I see that there’s an issue:
Hmmm, let’s see what is it about:
Ok, let’s go heck what is wrong with this version (I suspect it has to do with versioning):
Indeed. Ok, lemme:
- keep the proper version
- resolve the conflict
- continue rebasing and
- force the push
The most important part of such a rebase is to eventually force the push, so that a rewrite occurs in the history’s tree.
Happy King’s Day!
So, I’ve written a simple Math library and distributed it as an npm package. For testing purposes, jasmine-node is used.
However, when it came to testing my logarithm functions, the supported methods didn’t totally fit my case. Specifically, I wanted to use to test that a log(0) equals to negative infinity. Having already used similar methods of the library, such as toBeNaN(), I was expecting that a similar method (i.e. toBeNegativeInfinity() ) would also exist.
Nonetheless, it didn’t and of course one could easily argue “why not working around it, like toEqual(-Infinity) ?”, but then, what is the point of having methods like toBeNaN()? We could also work around this with toBeEqual(NaN).
So, I decided to extend it a bit, because I didn’t want to wait math.js already had a dependency on jasmine-node package, so, I had to provide my own (extended) version of jasmine-node. How could I do this?
- Fork jasmine-node
- Clone the forked repo locally
- Extend the library to my liking
- Distribute a new npm package out of the extended library (1)
- Replace jasmine-node dependency with jasmine-node-xt (2)
- Use the desired method as initially
(0) : Following the concept of also extending the library I used, instead of just providing a PR and wait whether it will be accepted or not, I saved time from something that might never happen in the future from my side; on the other hand, I gained knowledge on an area I am not so experienced, so, even if the submitted PR is not gonna be accepted, I learned something new!
(1) : Required changes in package.json; here you also have to keep in mind the provided license from the original library – it might affect the way you wanna distribute your extended version of that library
(2) : First uninstall jasmine-node : npm uninstall –save-dev jasmine-node and then install our version: npm install –save-dev jasmine-node-xt