Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Habits of a Happy Node Hacker

blog.heroku.com

Post reply on HN
Print view View original

31–40 of 56 posts

Re: Habits of a Happy Node Hacker

#31

Post by LukeB_UK »

vog wrote: post #15
secretagent wrote: post #2

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?

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

Re: Habits of a Happy Node Hacker

#32

Post by sisk »

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…

You're not necessarily wrong (that a ton of modules will be downloaded) but there are two points worth mentioning.

1) you can install from cache with something like:

  npm install --cache-min 9999999
2) npm's infrastructure has scaled extremely well. Gone are the days of spotty uptime and slow resolution. I maintain an npm proxy for one of—if not the—single largest consumer of npm modules and other than the very occasional 502 blip, npm has been rock-solid.

Re: Habits of a Happy Node Hacker

#33

Post by detaro »

userbinator wrote: post #11
sonnyp wrote: post #5

Earlier quoted context omitted.

It was an npm issue, fixed in npm 3. http://www.felixrieseberg.com/npm-v3-is-out-and-its-a-really...

I may be somewhat biased because my primary platform is Windows, but IMHO 260 bytes is plenty for a full path. I've personally never run into that limit with what I do, but I'm aware that there are some programming languages and environments which even encourage very deep nesting (often with directories that contain nothing more than another one), making it much harder to navigate the resulting structure. It's good t…

The annoying thing is that the limitation only exists in some APIs. So you can create paths that are to long, but then most software can't deal with them, which is worse than not allowing long paths at all.

Re: Habits of a Happy Node Hacker

#34

Post by chowes »

Kiro wrote: 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?

In your current state, clustering is probably not be the best advice for your use case.

That being said, if you are planning on scaling, you'll likely be moving your map object into it's own process, or a more traditional database, etc. Then whatever node application you have that facilitates the communication between that db/process and your users (via websockets or http) will be the place where clustering will come in handy.

Re: Habits of a Happy Node Hacker

#35

Post by jasim »

sisk wrote: post #32
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…

You're not necessarily wrong (that a ton of modules will be downloaded) but there are two points worth mentioning. 1) you can install from cache with something like: npm install --cache-min 9999999 2) npm's infrastructure has scaled extremely well. Gone are the days of spotty uptime and slow resolution. I maintain an npm proxy for one of—if not the —single largest consumer of npm modules and other than the very occas…

Thanks for clarifying.

I'll try the cache-min flag. But I suspect that if the cache contains packages with unresolved dependencies, then they'll also be of no use, and have to be removed too.

Also npm's servers has never given any trouble, the issue was always with my networks.

Re: Habits of a Happy Node Hacker

#36

Post by angersock »

Kiro wrote: 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?

Clustering is useful mainly when your app gets large or when you are handling redundancy. If you aren't doing that, your app is small enough not to need it. :)

If you want a fun exercise, try monkeypatching your global objects (map, players, etc.) to have getters/setters/etc. that transparently handle the syncing stuff.

Re: Habits of a Happy Node Hacker

#37

Post by albinofrenchy »

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.

If you are grabbing from an external repo, the spotty network is going to mess you up either way. If it's internal and your internet is that spotty, consider hosting a local npm cacheing server like this -- https://www.npmjs.com/package/sinopia.

My only issue with this technique is that 'npm start' and the rest aren't smart enough (please correct me if I'm wrong and there is a way to make it care!) to grab dependencies if you upgrade a dependency version and check that in.

Re: Habits of a Happy Node Hacker

#38

Post by habitue »

Kiro wrote: 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?

Your app should be clustered, and your db (where your state should live) can be clustered too. Ultimately you want as little state in your app servers as possible, since this makes it harder to scale them out, reboot them etc.

That's the ideal case anyway, its hard to avoid session state with websockets etc, but you can still push a lot down to the database layer

Re: Habits of a Happy Node Hacker

#39

Post by k__ »

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…

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 break happily.

This happens far too often for my taste and can (as far as I know) only be solved with third party software.

Re: Habits of a Happy Node Hacker

#40

Post by hunterloftis »

k__ wrote: post #39
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…

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.

Post reply on HN