Live data from Hacker News

Habits of a Happy Node Hacker

blog.heroku.com

41–50 of 56 posts

Re: Habits of a Happy Node Hacker

#41
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…

(bundling node_modules into git is definitely not an option)

Re: Habits of a Happy Node Hacker

#42
post #22

Ironically, right after the author mentions "The leading edge of developers are simplifying their builds" w/ vanilla JS, he suggests using Babel to get bleeding edge JS features...

The need for babel will (hopefully) go away in the future, though. So using ES6 features with Babel will end you up with a simpler project eventually, as opposed to writing ES5 with some libraries to do the same.

Re: Habits of a Happy Node Hacker

#43
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…

You can solve it with the npm shrinkwrap workflow mentioned in the article. It takes somewhat more effort, but locks down the full dependency tree. People have historically experienced a lot of issues with shrinkwrap in older versions of npm; I'm optimistic that npm 3 solves a lot of them.

Yes, I hope for npm3 too, but at the moment everyone in my team tells me it is far to slow to use it for anything :\

Re: Habits of a Happy Node Hacker

#44

Kind of a random question. What's the state of generator based control flow? Is this the future "habit" of a node hacker?

async/await is built on generators and promises.

Sorry I haven't followed the node community for a while. Are you referring to this: https://github.com/yortus/asyncawait?

Is this becoming popular / the new standard?

Re: Habits of a Happy Node Hacker

#45
post #19

#4 seems spurious. Just another example of "If everyone did it my way, then everyone would be doing it my way." What if people don't want to do it your way? What if people can actually remember to spell correctly? EDIT: *nix has case-sensitivity so that people can actually use it.

It isn't about spelling. It's about behavior that will be presumed correct in one environment but not in another. It's about portability. For another node example - in Linux, you can successfully use paths like `let filepath='foobar/' + filename`. That's correct in the given environment. However, such code will break when run in Windows. This is why `let filepath = path.join('foobar', filename)` is a superior solutio…

Windows supports regular / symbols in pathnames. What system doesn't?

Re: Habits of a Happy Node Hacker

#46
post #39
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…

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 small bursts on the regular, and only lock down (via shrinkwrap or Docker images) for QA/release builds.

Re: Habits of a Happy Node Hacker

#47
post #25

> Cluster your app How is this possible in my multiplayer game where the whole world lives in the program? E.g. var map = [...] and then map[x][y] when I want to use it, var players = [], players.push(newPlayer) etc. How can I share this state in a cluster?

Would Redis solve your problem?

Re: Habits of a Happy Node Hacker

#48
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…

Pick your poison, big dependencies or big repo + duplication. But the author is correct, the node way is to put deps in package.json and `npm i`.

Re: Habits of a Happy Node Hacker

#49
post #39
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…

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…

Pick your poison, locked down deps that you constantly change the x.x.1 version of, or the potential for the situation you describe.

That actually isn't supposed to happen, because semver means don't do anything breaking in a patch release (or a minor release). Not that the system works perfectly, of course.

Re: Habits of a Happy Node Hacker

#50

Regarding point 9, if you don't check your `node_modules` into version control don't you run the risk of them disappearing from NPM?

Do you guys not use pip, and stuff? I'm surprised by all the confusion on this point. Package managers are part of modern programming platforms. Repos only need to have your code, not everyone else's.
Post reply on HN