Falcor & why you should care about your Bithound score
Falcor has been extremely successful.
Falcor core was immediately considered one of the main JavaScript modules and it’s sister modules are well-liked as well. As part of helping Falcor be as successful as possible, I want to raise awareness of Bithound scores (which are already being used by the Falcor project), and point out why they matter.
What influences your Bithound score?
- The security of packages used
- Adherance to semver (Falcor doesn’t adhere)
- (Up|Out)dated packages
- Adherance to consistent style
- Whether or not issues are addressed within a timely matter
- …
Most everyone knows the above are important to the success of an open source module.
Weaknesses of the Bithound score (Falcor’s score should be higher)
While all of the above are important, they are less important (by far) for devDependencies than for dependencies proper. While Falcor locks down the few deps it has (this is shockingly rare but good on the Falcor team), dev deps are with the caret and some of the modules used are way out of date. In other words, I think the Falcor score should be higher than it is.
We should still improve the little things that matter
In terms of adherence to Node & NPM best practices however, Falcor core can improve. A quick comparison using Bithound.
Falcor Path Utils (another falcor project)
KeyKey (an insignificant project of my own)
Falcor core
Size is part of this, and stats aren’t everything. However, in my modules I’ve found a strong correlation between my maintenance of them and what the Bithound score ends up being.
I’m going to open some issues & PRs to address this, and I encourage other, both inside of Netflix and without, to do so as well.
Cheers!