Habits of a Happy Node Hacker • Hacker News Board

Re: Habits of a Happy Node Hacker

#51

Post by iamsohungry » Wed, Nov 11, 2015, 7:36 PM UTC

mkozlows wrote: post #46

k__ wrote: post #39

Earlier quoted context omitted.

I found the versions a bigger problem. I install something --save and get "^1.0.0" into my package.json, which resolves to 1.0.0 Someone installs my stuff and on her machine it resolves to 1.0.3 and nothing works anymore, even if she cloned an exact copy of my repository etc. Next step is to lock down all versions in my package.json, so all wildcards are gone. But the packages I depend on still have wildcards and can…

This is what you want to happen. The alternative is, you shrinkwrap everything and lock it down, and your dependencies never change. Except that now it's been a year, and you want to update your dependencies, and it's this huge jump that requires so many changes that it's going to take a month of concentrated pain to do, so you never do it, and welcome to the world of legacy code. Take your dependency-update hits in…

> This is what you want to happen.

Uh, no, I don't want my dependencies to break out from under me, thanks.

This is a major problem with the JS culture that I cannot stand. Too many JS devs can't be bothered to write software that doesn't suck, and so they try to instead tell their users their crappy problems are actually what they want. No, if you push changes to a library that break your library users' software without warning and a reasonable upgrade plan, you're doing a bad job.

> The alternative is, you shrinkwrap everything and lock it down, and your dependencies never change.

Or I use dependencies that upgrade their dependencies intentionally instead of whenever the `^` does it for them. The problem is that most of the JS packages out there are garbage software that doesn't do that. So it's necessary to be careful and only use dependencies which are well-maintained and reliable. ...which isn't unique to npm or a new problem, it's been well-known since all the way back when CPAN was new. Just because installing libraries is easy doesn't mean it's a good idea.

> Except that now it's been a year, and you want to update your dependencies, and it's this huge jump that requires so many changes that it's going to take a month of concentrated pain to do, so you never do it, and welcome to the world of legacy code.

Or you can do your job like a competent professional and don't wait a year to upgrade your dependencies. Again, fewer, more reliable dependencies helps with this; if you are using reasonable dependencies, they'll push few breaking changes and give warnings and reasonable upgrade plans.

Re: Habits of a Happy Node Hacker

#52

Post by dang » Wed, Nov 11, 2015, 7:42 PM UTC

douche wrote: post #10

Until I looked at the actual title of the post, I was a little concerned that somebody had invented a time machine. It's been changed now, but originally was titled "10 Habits of a Happy Node Hacker (2016)"

The "10" violated the guidelines explicitly (magic numbers in titles are supposed to be removed) and the "(2016)", while fine in principle, is ambiguous with HN's convention for annotating years. So we took those out.

Re: Habits of a Happy Node Hacker

#53

Post by hunterloftis » Wed, Nov 11, 2015, 7:58 PM UTC

cvburgess wrote: post #13

The article suggests using node-foreman (#6); can someone explain the advantage of Procfile-based environment management? I read the docs and didn't see anything that couldn't be handled by a simple config.json or some environment variables.

Node-foreman does use environment variables.

The usefulness of the tool (vs just straight env vars) is mostly in its ability to:

1) start multiple processes at once during local dev, much like a process manager can on a platform like Heroku or a compose file can in Docker. For instance, I'm working on a system now that uses `web`, `game`, and `sms` processes - which can all be started together via `nf start`, and then when one crashes during development the whole system spins down.

2) inject env vars into a local app via `.env` files (similar to your config.json example)

Re: Habits of a Happy Node Hacker

#54

Post by vog » Wed, Nov 11, 2015, 11:51 PM UTC

LukeB_UK wrote: post #31

vog wrote: post #15

Earlier quoted context omitted.

Even when assuming availability, what about modules that change? Either because authors "bugix" their existing versions and don't bother to increase the version number. Or because a malicious network actor delivered modified code. That's why I prefer to add a SHA-256 hash/checksum to every downloaded dependency file. In some settings that hash might be more important than the actual version number.

npm only lets you publish a version once, if the version number already exists for that module, you have to change the version number

Okay, that's good to know.

But I'm still uneasy with this, as the crypto hash approach provides some more safety features. For example, it protects against attacks the NPM platform itself (assuming they happen after you incorporated the library into your project). Also, it enables us to download the package from any other source (e.g. some archive/mirror), via plain HTTP, while still being safe from downloading a modified package.

That's why I still wish the crypto hashes were included in package.json (automatically on "install --save-exact", of course).

Re: Habits of a Happy Node Hacker

#55

Post by k__ » Thu, Nov 12, 2015, 10:33 AM UTC

iamsohungry wrote: post #51

mkozlows wrote: post #46

Earlier quoted context omitted.

This is what you want to happen. The alternative is, you shrinkwrap everything and lock it down, and your dependencies never change. Except that now it's been a year, and you want to update your dependencies, and it's this huge jump that requires so many changes that it's going to take a month of concentrated pain to do, so you never do it, and welcome to the world of legacy code. Take your dependency-update hits in…

> This is what you want to happen. Uh, no, I don't want my dependencies to break out from under me, thanks. This is a major problem with the JS culture that I cannot stand. Too many JS devs can't be bothered to write software that doesn't suck, and so they try to instead tell their users their crappy problems are actually what they want. No, if you push changes to a library that break your library users' software wit…

So true...

But I have to admit, the problems I mentioned only occur about once a month and only cost a few hours to fix and we have over 100 dependencies.

If we wouldn't use so much third party stuff we would probably end up fixing this every few months, which is okay-ish.

Re: Habits of a Happy Node Hacker

#56

Post by Pr3fix » Thu, Nov 12, 2015, 3:16 PM UTC

albinofrenchy wrote: post #37

jasim wrote: post #29

> As long as each dependency is listed in package.json, anyone can create a working local copy of your app - including node_modules - by running npm install. But it is going to download the internet, will take forever, and if the network is patchy, any dependencies that weren't downloaded will remain unresolved, even if you reinstall the package, and you'll have to manually install them with the help of `npm list`, o…

Either way you are going to have to potentially download a lot of stuff; I'd rather not have that bloat integrated into the repo. Also consider if you come onto a project and they've upgraded a library version multiple times, when you clone from the repo you are going to grab every revision they've ever used and checked in. This is going to be much bigger and slower than the equivalent npm install for that package. I…

If you're checking your `node_modules` into the repo you're doing it wrong :\ should just check in package.json.