Hacker News Reader

Comment by TazeTSchnitzel | Hacker News Reader

Comparing node to PHP is a little unfair. PHP works!

Comparing node to PHP is a little unfair. Node has a great package system, JavaScript is an evolving language that run almost everywhere: in all browsers, server side, in devices. PHP started as a simplified Perl, is a web page preprocessor that works well in that context: it can be used server side but almost nobody do it.

> Node has a great package system

Having used both, Node's package system is horrific compared to PHP's Composer. Composer's built-in composer.lock system is something NPM sorely needs by default.

It exists (npm shrinkwrap [1]), but it's not enabled by default, and it has some warts, such as non-deterministic sorting of entries.

There's a third-party tool [2] that is supposed to solve many of the issues, but I haven't tried it.

Of course, if you do this, there's a decent chance that if you try installing it again in 6 months, your shrinkwrapped version of at least one of the dependencies won't be available any more...

[1]: https://docs.npmjs.com/cli/shrinkwrap [2]: https://github.com/uber/npm-shrinkwrap

One wonders, why shouldn't it be 'npm lock'... I'm not that into plastic packaging, and not a native speaker, so shrinkwrap gives me as much clue about what the command does as blinktap, or pricklywarp.

Yeah, I've been experimenting with shrinkwrap.

Biggest wart I've encountered is I've got a package that installs fsevents (OSX-only) as one of its optional dependencies. When I shrinkwrap and attempt to install on a Linux server, that optional dependency is treated as a required one, and it can't install. I have to manually zap it from the JSON. :-/

Oh sure, but it works like a shotgun jetpack pointed at your foot.

I disagree. I think node is unlike anything we've seen thus far. It's not php, it's not python and it's not ruby.

I, literally, cannot rebuild my application from a year and a half ago that is standard node + npm. The deps are broken...the code won't build with node-gyp...i mean node-waf...i mean who knows? What a mess and a HUGE regret.

> I, literally, cannot rebuild my application from a year and a half ago... The deps are broken...

Welcome to the Cloud Future Web 3.0, where every library you use is maintained like some random guy's personal homepage, and his robots.txt prevents you from caching a stable copy.

I don't understand this argument. If you know what parts of your site the deps will effect it should be trivial to update them incrementally and rollback the commit if one unexpectedly breaks your code.

Besides, there's no universal unwritten rule stating that you have to use the bleeding edge version of every dependency.

Keeping all dependencies up-to-date is mostly in the interest of widely used libraries not one-off applications.

Not sure what the OP's problem was, but I've had issues with old libraries where some dependencies have been removed from npmjs.com. It's totally ridiculous.

I solve such problem for our clients by packaging every dependency we use in project as independent RPM package, so whole application can be installed using single "yum install ..." command from local repository without need to connect to internet. It allows us to precisely control version of libraries we use and also allows to apply patches to them when a problem is found.

So it's not immutable? Blinkin' egg, I'm happy I only played with node.js now. On the other hand, I guess it's always better to vendor one's deps, at least those that are not packaged by the operating systems. The language specific package managers add a lot of complexity.

I haven't seen the disappearing libraries from registry.

I did find a few libraries that have been completely abandoned...like 2/3 of the libraries I used.

I went as far as pulling the node_modules directory from production and perfectly matching the node version on my local machine. Linux -> linux and the app won't run locally. I think it's because the node-gyp influenced deps need to be built locally and linked to the right libs.

I then spent a few hours downgrading each version to isolate the issue...found a few libraries that were hard-deprecated (which was nice), found some breaking changes in the node version I'm using and then I just gave up.

Sure, but--as the traditional rant (http://blog.codinghorror.com/the-php-singularity/) goes--it works like a claw hammer with two claws and no face: sure, you can turn it sideways and drive nails with the middle part, but wouldn't it be easier to just get a hammer?

That is a bad tool only if you want to use it for driving nails. A claw hammer with two claws and no face is a magnificent tool for pulling out nails.

Rails is a hammer with a normal head but no claw. Hammering nails in is the more common case, but if you need to do both you're better off with the two-clawed one.

Reply on news.ycombinator.com