141–150 of 279 posts
Earlier quoted context omitted.
But it's great for resume and portfolio.
This is the problem - how to disincentivise that behaviour?
Earlier quoted context omitted.
But it doesn't work for libraries people will be using in development. Often you are waiting for a handful of packages to introduce specific features or bug fixes and need them the moment they are available. NPM isn't user space, it's dev space. Timeliness is the maxim.
I’m not a JS developer so maybe I’m missing something, but how do you use a library during development and not use it in production? In the C++ world, I can’t imagine a situation where you would need to depend on, for example, libjpg while developing, but not need to read JPEG files in prod/end-user-space.
Check out Electron or React starter apps for an example, their boilerplates should have dozens of examples.
The real issue the Balkanization of JavaScript programs. The `rate-map` package is essentially one line of code: start + val * (end - start); https://github.com/shinnn/rate-map/blob/90c234c9/index.mjs#L...
The real issue is most JS programmers are not smart enough to write it so they have to find packages to do anything.
I don't want to ban you, but when accounts keep doing this, we kind of have to.
Earlier quoted context omitted.
But it doesn't work for libraries people will be using in development. Often you are waiting for a handful of packages to introduce specific features or bug fixes and need them the moment they are available. NPM isn't user space, it's dev space. Timeliness is the maxim.
I’m not a JS developer so maybe I’m missing something, but how do you use a library during development and not use it in production? In the C++ world, I can’t imagine a situation where you would need to depend on, for example, libjpg while developing, but not need to read JPEG files in prod/end-user-space.
Earlier quoted context omitted.
I trust these people to manage software packages: https://nm.debian.org/public/people/dm_all They “only” manage ~18K packages, but those 18K do a lot more than NPM: https://people.debian.org/~corsac/ perhaps number of packages is the wrong metric.
A lot of those packages are going to be versions months or sometimes years behind the latest version. I'm not convinced this is a model that can work for programming libraries.
eg write some code in a JS framework, then go off and do something for 18 months. Come back and there's a very good chance the entire framework has been obsoleted and replaced, perhaps even several times.
In JS land that's "Doh, well of course!".
In sane ecosystems (eg not Ruby), not so much. ;)
Earlier quoted context omitted.
I trust these people to manage software packages: https://nm.debian.org/public/people/dm_all They “only” manage ~18K packages, but those 18K do a lot more than NPM: https://people.debian.org/~corsac/ perhaps number of packages is the wrong metric.
> but those 18K do a lot more than NPM This is so hilariously wrong it's actually shocking it was written?
Earlier quoted context omitted.
npm's size is not independent of its curation strategy. This can be construed as a good or a bad thing.
NPM's size is first and foremost dependent on the popularity of JavaScript. All other "modern" (where "modern" is "last 20 years") package managers have zero curation. Perl, Python, Ruby, Go, Rust, Dart, JavaScript. You say: "if they had curation, they would be better". I say: "if they had curation, they would have lost to a competitor that doesn't have curation". People care about having more packages much more than…
You're partially right. Some people haven't yet learned (eg the hard way, or whatever) that quality does matter.
Hopefully most of those people will learn to appreciate and demand quality over time, instead of the current anything-goes-approach.
In the meantime, things like this npm package example will continue to give npm/javascript black eyes (repeatedly) and help make that happen. :)
Earlier quoted context omitted.
It does work, in practice, and has for years. Every package in the Debian (or Ubuntu, or FreeBSD, etc.) package repos depends only on other packages in those repos and on the base OS. It works fine. Packages being months behind the latest version is a feature, not a bug — it means things will only be randomly changing under your feet rarely, with the exception of security fixes.
> Packages being months behind the latest version is a feature, not a bug — it means things will only be randomly changing under your feet rarely, with the exception of security fixes. If things are "randomly changing" by updates, that means the upstream package isn't following semantic versioning practices, and more importantly, isn't preserving backwards compatibility with their releases. That's a mark of bad softw…
It's definitely not used as often as in npm packages, but you can use =version after your package name to apt install a particular version, or apt pinning for more complex setups.
Earlier quoted context omitted.
shinnn is claiming his account was hacked, and the hacker added the code. Generally if a hacker hacks someone's npm account and adds harmful code, that would be considered malicious and an exploit.
That's obviously a lie though.
So instead of going on a lone and not-fully-backed-up crusade accusing shinnn of lying that could wind up in a he-said-she-said situation with negative fallout, Harry instead decided to use shinnn's words for his own benefit, and hype it up as a serious NPM account hacker inserting malicious code.
Earlier quoted context omitted.
It's an ecosystem full of reinventing the wheel. The most popular library, lodash, includes a reimplementation of a foreach loop for Pete's sake, for reasons passing understanding since it's part of the ecma spec. JavaScript is just amateur hour, and these things are going to keep happening. It's pathological.
Which foreach are you talking about? Array.prototype.forEach, for...in loops, for...of loops? The first only works with arrays and array-like objects. The second works on objects and arrays, but it iterates over all enumerable properties, so you don't want really want to use it for arrays. It's also made a lot less useful because it only iterates over properties, not keys. The third finally provides some sanity, but…
That said, you can use `Object.keys`, `Object.values`, or `Object.entries` if you want to iterate over objects that don’t implement `Symbol.iterator`, so if you only need `_.forEach` there is no reason to pull in any libraries.
Object.entries(object).forEach(([key, value]) => {
// ...
});