> npm’s download stats are naïve by design: they are simply a count of the number of HTTP 200 responses we served that were tarball files, i.e. packages. This means the number includes:
>
> automated build servers
>
> downloads by mirrors
>
> robots that download every package for analysis
When we talk about how we can help the planet climate change wise, there has to be a huge amount left on the table when it comes to build environments recreating themselves from scratch multiple times a day (CI/CD without "proper" caching) at a huge scale
I wonder what 1 person driving an EV does for the planet vs 1 commercial airliner vs 1 developer implementing "cache" at a huge company/project
I do have to say that was the silver lining to Docker Hub starting to rate-limit. So many people finally got around to implementing caching once it broke builds, and then it was usually accompanied by realizing that they’d left a significant amount of build time on the floor for what was usually a very modest amount of work.
There's also a 'is-even' package, which depends on 'is-odd', which in turn, depends on 'is-number'.
'is-odd' is a little bit more involved than 'is-even'. What it does, is:
> Returns true if the given number is odd, and is an integer that does not exceed the JavaScript MAXIMUM_SAFE_INTEGER.[0]
The full implementation of 'is-number' is as follows:
'use strict';
module.exports = function(num) {
if (typeof num === 'number') {
return num - num === 0;
}
if (typeof num === 'string' && num.trim() !== '') {
return Number.isFinite ? Number.isFinite(+num) : isFinite(+num);
}
return false;
};
Ridiculous as it may be, my guess is that provides a unified way of number checking while avoiding the pitfalls or crazy consequences which could arise from divide-by-zero[1], which I guess might prevent less-experienced folks from tripping up on some of the Javascript gotchas? I'm not really sure. That being said, I have seen those package dependencies in some serious stuff.
Do I agree? I'm not really sure to be honest. Probably not.
I think that's really the issue here. It's not that these packages exist and aren't useful to less experienced devs or people new to JS just trying to get a task done, it's these packages keep showing up in professional/enterprise apps and libraries. Those devs should already know how to do this stuff. It seems odd these projects would leave themselves vulnerable to supply chain attacks over something so trivial.
Really? I'm not a JavaScript dev but this is pretty inscrutable. I think its totally reasonable for devs to expect not to have to do all this byzantine casting and comparisons just to find out if a variable contains a number. You're right in the sense that an experienced dev should know to vendor this or reimplement in code they control rather than downloading it every time they build, but the necessity of this library is more of a damnation of the JS stdlib than anything.
Why hasn't a Javascript equivalent of the Apache Commons Java library (or similar) been developed?
When I was a Java developer just about everybody used it - Lots of widely used, tested, organised, and trusted utility functionality: https://commons.apache.org/
Presumably most decent packaging tools will strip out any unused code, it stops less experienced developers reinventing the wheel and importing another dependency without thought.
This package exists not because JS or its runtimes (like Node, Deno) lack capabilities, but because people like Jon Schlinkert - a proud author of 1447 packages - abused the registry.
is-number was first published 9 years ago, when these kind of micro-packages were in vogue. braces was added as a dependency to chokidar over 6 years ago [1]. And if it ain't broke, don't fix it. I don't think the average JS dev today is going out and pulling in these deps.
11 comments
[ 2.9 ms ] story [ 38.9 ms ] threadWhen we talk about how we can help the planet climate change wise, there has to be a huge amount left on the table when it comes to build environments recreating themselves from scratch multiple times a day (CI/CD without "proper" caching) at a huge scale
I wonder what 1 person driving an EV does for the planet vs 1 commercial airliner vs 1 developer implementing "cache" at a huge company/project
Then rebuilding a container when the dependent upstream packages hadn’t changed would do absolutely nothing.
Today we only chose between rarely rebuilding and excessively doing so.
'is-odd' is a little bit more involved than 'is-even'. What it does, is:
> Returns true if the given number is odd, and is an integer that does not exceed the JavaScript MAXIMUM_SAFE_INTEGER.[0]
The full implementation of 'is-number' is as follows:
Ridiculous as it may be, my guess is that provides a unified way of number checking while avoiding the pitfalls or crazy consequences which could arise from divide-by-zero[1], which I guess might prevent less-experienced folks from tripping up on some of the Javascript gotchas? I'm not really sure. That being said, I have seen those package dependencies in some serious stuff.Do I agree? I'm not really sure to be honest. Probably not.
[0] https://github.com/i-voted-for-trump/is-odd/blob/master/READ...
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
EDIT: removed redundant sentence
When I was a Java developer just about everybody used it - Lots of widely used, tested, organised, and trusted utility functionality: https://commons.apache.org/
Presumably most decent packaging tools will strip out any unused code, it stops less experienced developers reinventing the wheel and importing another dependency without thought.
Makes me question on just what sort of grounds are we building our systems on...
is-number was first published 9 years ago, when these kind of micro-packages were in vogue. braces was added as a dependency to chokidar over 6 years ago [1]. And if it ain't broke, don't fix it. I don't think the average JS dev today is going out and pulling in these deps.
[1] https://github.com/paulmillr/chokidar/commit/cbdf25563cfff7f...