Live data from Hacker News

I've Just Liberated My Modules

medium.com

421–430 of 827 posts

Re: I've Just Liberated My Modules

#421
post #169

Earlier quoted context omitted.

What if such a system was implemented using IPFS[0] (or similar) for storage? [0] https://github.com/ipfs/ipfs

I'm surprised all package managers don't use an IPFS-like system that uses immutable state with mutable labels and namespaces. Now that IPFS exists, and provides distributed hosting, it's even easier.

As much as I agree, IPFS is still very much under construction and I don't think any known package managers got started after IPFS was reliable.

You can experiment with ipfs-backed git remotes though. That's already possible.

Re: I've Just Liberated My Modules

#422

Earlier quoted context omitted.

> but my thoughts right now are ... "I would never use NPM again if I knew how catastrophically badly designed it is" Then the protest was effective.

only in the most narrow sense. His cause, whatever it is, isn't furthered, but now everyone involved (including him) looks bad, and a lot of innocent people have had their time wasted fixing something that shouldn't have broken. It's a loss for everyone involved. He looks petty and untrustworthy, npm looks amateurish, kik gets bad publicity, and everyone using this junk is stuck with their face in their palms.

Don't blame the guy who pressed a button that allows you to unpublish a core module. Sure, it was done on purpose this time, but what if it happened by accident. Your "package manager" shouldn't be this fragile.

Re: I've Just Liberated My Modules

#423
post #397

Earlier quoted context omitted.

"So what you're saying is, your computers cannot possibly not continue damaging the plaintiff's interests." "That's correct." "You're being honest with me." "Yes, your Honor." "Will the computers continue harming the plaintiff's interests if shut off?" "... That would be dreadfully inconvenient, your Honor." "Do you have a more convenient solution?" "No, your Honor." "You are hereby ordered to turn off your computers…

How about a blockchain-based NPM? Can't take all the computers down. Legal, shmegal.

You can still be jailed for contempt of the order, though.

"I've found a clever workaround for court orders" doesn't work around that bit.

Re: I've Just Liberated My Modules

#424

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/Unix_philosophy

In this case the npm ecosystem is providing more of a surrogate standard library. Imagine if there were no libc, for example, and so people had to reimplement all those functions; would you really want one package per function because of how "Unix philosophy" it would be? This is where the JavaScript ecosystem is right now -- JS doesn't have the kind of robust standard library other languages take for granted, so you…

I don't understand the standard library argument at all. Standard library is always limited, there is always something that's not included - then what?

This has nothing to do with the JavaScript standard library but the insanity of NPM. There are modules that have even more dependents than `pad-left` despite being included in the standard library (e.g. https://www.npmjs.com/package/date-now, https://www.npmjs.com/package/is-positive, https://www.npmjs.com/package/is-lower-case)

Re: I've Just Liberated My Modules

#425
post #217

Earlier quoted context omitted.

The main point in support of your argument is the fact that Unix utils are bundled in larger packages instead of shipping in single-command packages. Think of Fileutils, Shellutils, and Textutils... which got combined to form Coreutils! Ha! That leaves only Diffutils, for the time being anyway.

But none of Fileutils, Shellutils and Textutils was ever as tiny as many npm or gem modules. I thought how commands are bundled into packages was the entirety of what we were discussing. That was my interpretation of larkinrichards's comment (way) up above. Packages are the unit of installation, not use. Packages are all we're arguing about. My position: don't put words in God's mouth :) The unix way is commands that…

Underscore/lodash is a great bundle of functions that do simple things well. And it's a tiny enough library that there is really no need to split it into 270 modules.

I support packages of utility functions. Distributing them individually is a waste of resources when you have tree shaking.

I trust a dependency on lodash. I don't trust a dependency on a single 17 line function.

Re: I've Just Liberated My Modules

#426
npm really shouldn't let authors unpublish. It should definitely be impossible to overwrite a published package version (it is, but only for the past year or so).

When you install express, you install 40 dependencies. Each of these has separate maintainer(s) and coordination is optional. If we're going to allow this dependency mess to grow organically, npm needs to be strict about what gets published and we need to be really careful about depending on anything but a strongly pinned version.

Re: I've Just Liberated My Modules

#427
post #24

This is why you should vendor it. What is "it"? All of it, whatever it may be. You should be able to build your systems without an internet connection to the outside world. I say this with no reference to particulars of your language or runtime or environment or anything else. This is merely a specific example of something that could happen to a lot of people, in a lot of languages. It's just a basic rule of professi…

Or have a decent package management setup? Or just use an existing one, it's been working for 20 years. Package management is a solved problem, just use an existing one and move on.

Re: I've Just Liberated My Modules

#428
post #348

Reading some of the comments reminds me old tale about a young man, that every morning on his way to work passed by a beggar and gave him a coin (that was back when coins actually had some value). One morning though the beggar notices the coin is smaller than usual, and he asks: - Why you gave me a different coin today? and the young man says: - I got married and now I'm starting a family, I need more money so I can…

> But let's not lose the perspective - the author does not owe us or npm continued support

On the other hand, he wanted his work published in the community registry where they got exposure and were made into dependencies in lots of projects.

When the author offered their modules and then suddenly walked away with them, lots of innocent devs who built their projects with his modules got hurt. He did more bad than good overall, especially that he unpublished hundreds of modules at once without warning, not just one. He should carry some responsibility for that.

The author can publish and unpublish all he wants from his personal site where there are zero expectations that it will continue to exist, but when he's doing it from a public repository where he received a lot of confidence from the community, he should at least make sure his users don't suddenly fall flat. Now people will start wondering if a module with millions of installs in the last month is still going to exist tomorrow.

Re: I've Just Liberated My Modules

#429

Earlier quoted context omitted.

Unless you're npm: https://twitter.com/seldo/status/712414400808755200

That's pretty interesting. I wonder if it's within npm's legal right to distribute someone else's IP in such a way that they do not desire. Granted the license is WTFPL but does that include taking over the IP itself?

Uh... which part of "DO WHAT THE FUCK YOU WANT TO" is actually unclear here? Is there a word or phrase that you're not grasping?

"DO WHAT THE FUCK YOU WANT TO" clearly includes not only taking over the IP but also RE-LICENSING IT under whatever terms you like. That's kind of what "DO WHAT THE FUCK YOU WANT TO". Do. What ever the fuck. You want to.

How is this unclear? I'm kind of baffled.

Re: I've Just Liberated My Modules

#430

Earlier quoted context omitted.

Why would this be a bad thing? I don't need a random number generator if I just want to allocate memory.

Because a lot of little libraries makes namespaces more complicated, makes security auditing more difficult, makes troubleshooting more difficult as you have to start digging through compatibility of a ton more libraries, makes loading slower, because you have to fopen() a ton more files and parse their contents, etc. Add on top of that those little libraries needing other, probably redundant little libraries, and yo…

Some of this things you mention are true, but:

> makes security auditing more difficult

What? If you go all the way, you just review all dependencies too. And if they have a good API, it's actually much easier. For example if your only source of filesystem access is libfilesystem, you can quickly list all modules which have any permanent local state.

Splitting huge libraries into well designed categories would make a lot of reviews easier.

> Having both of those as azer-random or something means that someone automatically gets all the dependencies, without having to make many requests to the server.

Also disagree. One-off builds shouldn't make a real difference. Continuous builds should have both local mirror and local caches.

Post reply on HN