Live data from Hacker News

I've Just Liberated My Modules

medium.com

721–730 of 827 posts

Re: I've Just Liberated My Modules

#721
post #609

Earlier quoted context omitted.

It's more like the young man telling the beggar that he can come cut the wood from his land for free. Then one day the young man stops letting the beggar cut his wood for free. He's not taking back the wood that's already been cut. The problem is if the beggar wasted the wood he did take, and took for granted the assumption that he would always be able to get more. Relying on something continuing to exist on the inte…

Interesting, but there is also the broken builds issue. 100% agree with your last sentence though.

Your builds are broken because your build process made the false assumption that you could always get another piece of wood. You could have used the first piece of wood you were given for your build over and over, but you chose to essentially toss out the piece of wood every time your build finished.

Re: I've Just Liberated My Modules

#722

The fact that this is possible with NPM seems really dangerous. The author unpublished (erm, "liberated") over 250 NPM modules, making those global names (e.g. "map", "alert", "iframe", "subscription", etc) available for anyone to register and replace with any code they wish. Since these libs are now baked into various package.json configuration files (some with 10s of thousands of installs per month, "left-pad" with…

Legally isn't it totally NPM as a company to publish existing versions of left-pad because those versions were already released under a license that allows redistribution, whether the author wants them to or not? Or can the author effectively veto this?

From what I can tell[0], left-pad was released under the "Do what the fuck you want public license"[1], so I suppose NPM can do whatever the fuck they want, including redistribution.

[0] https://www.npmjs.com/package/left-pad (although I suppose its possible the library was added after the package was re-added -- I don't see a license on the GitHub page)

[1] http://www.wtfpl.net/

Re: I've Just Liberated My Modules

#723
I think this blossoming episode leads me to believe that if you are running a production app, then you need to be hosting your own internal npm, and updating that from the global npm. That way when something like this happens you are able to continue on, and not have many issues, like the builds braking that are being reported on github.

Re: I've Just Liberated My Modules

#725
post #115

Here's [1] a list of all modules that were liberated. Some serious land-grab opportunities there [1]: https://gist.github.com/azer/db27417ee84b5f34a6ea

> Some serious land-grab opportunities there It sums up the biggest issue with npm. Modules shouldn't be a name but a namespace + a name , just like composer. Someone shouldn't be able to have a monopoly on names like "web" or "async". It should be "some-namespace/module-name".

Absolutely. All packages should be namespaced by org or author. This also brings up a very real malware injection possibility:

* User removes 'alert' from npm, last version was 1.1.0

* Consumers with "alert": "^1.0.0" now have broken builds

* Troll grabs "alert", publishes 1.1.1 with a "postinstall" hook that steals personal data / installs a trojan / deletes data

* Major numbers of development machines and some production environments are now compromised

Shrinkwraps should also include a package hash to protect users against the repository. I'm starting work on a PR to `ied` that will do this.

Re: I've Just Liberated My Modules

#726
post #66
post #29

Earlier quoted context omitted.

I'm using npm / browserify etc in anger for the first time today. This is a horrible issue to have run into and it's left a pretty sour taste. The fact that it's possible for someone to unpublish 17 lines of js and break the install of major bits of infrastructure for everybody is pretty insane. It seems like at a minimum the dependency tree should be traversed to see what the flow on effect will be. Should it even b…

I don't want to sound like a old grumpy man but here goes anyhow. I was looking into using node.js, react, etc after many years of writing web apps using Python and Quixote (obscure web framework like Flask). The whole Javascript technology stack looks pretty insane of me. Getting a working React environment requires a huge number of packages to be pulled down by npm. Browserify requires a bunch more. Recursive depen…

I've been using Mithril for about a year for multiple single-page apps and it's great. I'd definitely recommend it.

Re: I've Just Liberated My Modules

#727

Earlier quoted context omitted.

> For the record they made sure the exact same code was published to 0.0.3 so that I didn't maliciously inject anything. (elsewhere in this thread)

I assume they're talking about the kik module.

I was.

Re: I've Just Liberated My Modules

#729

this is why your dependencies should be checked into git

WOW. I've been doing the exact opposite for a long time now. Specifically with Nuget packages, because I could just trust that the package would be there. Considering that node_modules often has something like 4000 files in it, this seems like a huge problem to me. Especially considering the amount of redundancy in node_modules. Uggh... unfortunately if the trust of the package distribution sites is violated then the…

actually quite convenient: besides having piece of mind, it really simplifies builds and deploy, all for the cost of a few extra mb in your git

Re: I've Just Liberated My Modules

#730

Earlier quoted context omitted.

I've had deploys break because gems were removed from RubyGems.org. Using CI as a gate isn't sufficient because a gem can be removed in the window between a completed CI run and the deploy. Making it harder, generally if you have a gem installed locally you won't notice the problem until you need to install it on a fresh system. It used to be the case that a yanked gem was simply removed from the gem index, but the f…

Dear Everyone Doing Devops: do not build gems on your production servers. Build a tarball, test the tarball through dev/staging, deploy the tarball to production. For any value of tarball- literal tarball, deb/rpm (actually CPIO under the hood, but who cares), prebaked AMI (not tar at all), docker image (tarball of JSON + nested tarballs. Seriously, it's tar all the way down). Everything will be better. Roll forwards…

http://martinfowler.com/bliki/ImmutableServer.html
Post reply on HN