Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I will pay you cash to delete your NPM module

drewdevault.com

Post reply on HN
Print view View original

51–60 of 60 posts

Re: I will pay you cash to delete your NPM module

#51

Post by Abishek_Muthian »

nyx_land wrote: post #32

This is such an important topic that feels like it's hardly ever talked about. In the common lisp world, it's pretty much a cultural norm to use as few dependencies as possible and stick close to the spec, because part of the strength of CL lies in it having an extremely stable spec with a lot of high quality implementations. Adding dependencies reduces the stability of your project and potentially its portability, w…

I expect things to change after the recent series of high profile supply-chain attacks like that of SolarWinds, at-least with sensitive projects.

I wouldn't be surprised if the software development contracts outright blacklist aforementioned programming languages and ecosystems notorious for senseless dependencies in the name of 'Getting things done'.

Re: I will pay you cash to delete your NPM module

#52

Post by maccolgan »

velcrovan wrote: post #39
rahimnathwani wrote: post #33

Earlier quoted context omitted.

The article mentions this, and links to the same page.

Still, though, could there not be a similar scheme where instead of unpublishing the module, the maintainer intentionally inserts a divide by zero somewhere and pushes it as a minor update?

What would divide by zero do for a JS dependency?

Re: I will pay you cash to delete your NPM module

#53

Post by maccolgan »

l0b0 wrote: post #49
presentation wrote: post #20

I mean, that isArray example is exactly the kind of code that 99% of developers wouldn't come up with on their own, since it's not intuitive at all to check whether or not the value is an array in that way. If anything I would just be in favor of a name for the package that made it clear that it's intended for legacy compatibility.

That points to the underlying problem: a crap standard library. If extremely common functionality has to be outsourced to (short but) completely non-obvious third party modules, the standard library has failed at its core task.

JavaScript is in a situation different than most other languages. Any addition to the standard library has to be implemented by every browser on earth, and that's already unsustainable. Any imperfections or mistakes in the standard library (we are still distraught with the Referer bs) can't ever be fixed as all code has to be perpetually working.

Re: I will pay you cash to delete your NPM module

#54

Post by l0b0 »

maccolgan wrote: post #53
l0b0 wrote: post #49

Earlier quoted context omitted.

That points to the underlying problem: a crap standard library. If extremely common functionality has to be outsourced to (short but) completely non-obvious third party modules, the standard library has failed at its core task.

JavaScript is in a situation different than most other languages. Any addition to the standard library has to be implemented by every browser on earth, and that's already unsustainable. Any imperfections or mistakes in the standard library (we are still distraught with the Referer bs) can't ever be fixed as all code has to be perpetually working.

ECMAScript has gone through many revisions since its inception, so it is clearly possible to modify the language.

Re: I will pay you cash to delete your NPM module

#55

Post by NoGravitas »

nyx_land wrote: post #32

This is such an important topic that feels like it's hardly ever talked about. In the common lisp world, it's pretty much a cultural norm to use as few dependencies as possible and stick close to the spec, because part of the strength of CL lies in it having an extremely stable spec with a lot of high quality implementations. Adding dependencies reduces the stability of your project and potentially its portability, w…

I would say another thing about the CL ecosystem is that all the "little utility functions" on the order of left-pad are all bundled into one dependency — Alexandria — and there are a handful of other libraries that are cross-implementation compatible and widely enough used to be de-facto standards. Three or four dependencies in CL will often get you what would be hundreds of dependencies in JS.

Re: I will pay you cash to delete your NPM module

#56

Post by zirak »

19h wrote: post #48
presentation wrote: post #20

I mean, that isArray example is exactly the kind of code that 99% of developers wouldn't come up with on their own, since it's not intuitive at all to check whether or not the value is an array in that way. If anything I would just be in favor of a name for the package that made it clear that it's intended for legacy compatibility.

It’s also wrong because the representation wasn’t exactly always deterministic in 2013 across all js engines. The right way to check for an array is value.constructor === Array, which also doesn’t really make any sense because an array in JS really is just an object with a length key and respective keys names 0…n.

The constructor check would unfortunately not work for cross-frame arrays. Each frame has its own global object, with its own Array constructor. So:

    var iframe = document.createElement('frame');
    document.body.appendChild(iframe);

    var value = iframe.contentWindow.Array();
    value.constructor === Array // false
    value instanceof Array // false
    value instanceof iframe.contentWindow.Array // true
Stringifying the constructor works even for cross-frame values:

    value.constructor.toString() === Array.toString() // true
These days though, `Array.isArray` is the right thing to do, available since roughly 2010.

Re: I will pay you cash to delete your NPM module

#57

Post by throwaway19937 »

maccolgan wrote: post #53
l0b0 wrote: post #49

Earlier quoted context omitted.

That points to the underlying problem: a crap standard library. If extremely common functionality has to be outsourced to (short but) completely non-obvious third party modules, the standard library has failed at its core task.

JavaScript is in a situation different than most other languages. Any addition to the standard library has to be implemented by every browser on earth, and that's already unsustainable. Any imperfections or mistakes in the standard library (we are still distraught with the Referer bs) can't ever be fixed as all code has to be perpetually working.

That's just an excuse and a poor one at that. Many languages (C, Fortran, C++) have multiple implementations and don't get to fix design flaws in the standard library; JavaScript is not unique in these requirements.

The only special thing about JavaScript is that after 25+ years the standard library is still grossly inadequate.

Re: I will pay you cash to delete your NPM module

#58

Post by vlunkr »

NoGravitas wrote: post #55
nyx_land wrote: post #32

This is such an important topic that feels like it's hardly ever talked about. In the common lisp world, it's pretty much a cultural norm to use as few dependencies as possible and stick close to the spec, because part of the strength of CL lies in it having an extremely stable spec with a lot of high quality implementations. Adding dependencies reduces the stability of your project and potentially its portability, w…

I would say another thing about the CL ecosystem is that all the "little utility functions" on the order of left-pad are all bundled into one dependency — Alexandria — and there are a handful of other libraries that are cross-implementation compatible and widely enough used to be de-facto standards. Three or four dependencies in CL will often get you what would be hundreds of dependencies in JS.

JS has lodash as a very good (IMO) "little utility function" library. But for some reason people decided that instead they would rather shatter it into 1000 pieces.

Re: I will pay you cash to delete your NPM module

#59

Post by itstaken »

velcrovan wrote: post #39
rahimnathwani wrote: post #33

Earlier quoted context omitted.

The article mentions this, and links to the same page.

Still, though, could there not be a similar scheme where instead of unpublishing the module, the maintainer intentionally inserts a divide by zero somewhere and pushes it as a minor update?

That's how you break the web

Re: I will pay you cash to delete your NPM module

#60

Post by nokya »

The author forgot the "iTard" effect: once the author deletes the module, the disappearance of the feature will cause major turmoil and people will complain to the repository owners to restore it asap.

This will also create a new opportunity for someone else to...recreate the module, and chances are that it will likely include some malicious or even more broken code.

If you want to "improve" the situation, you update the module with code that triggers an exit with a warning message. That will fix the problem.

Post reply on HN