Hacker News Reader

Comment by benatkin | Hacker News Reader

Curious about performance of npm install, seems like it's one thing that could make it not so snappy. For compiled modules, does it have a decent amount of memory/CPU on the instances? How about connectivity? Does it use a mirror for NPM? Might it in the future?

View on HN

Our biggest focus is `npm install` performance. We have multiple caches to make it the best possible experience for you.

Every time you run `now` it's as if you had installed from scratch (including semver invalidations like ^ or ~). The focus is on reproducibility.

> Every time you run `now` it's as if you had installed from scratch (including semver invalidations like ^ or ~). The focus is on reproducibility.

This is very confusing to me as these seem to be contradictory statements. Installing "from scratch" (I take this to mean, as if node_modules is an empty folder) is not a reproducible action, as all it takes is one sub-dependency releasing a new version to change your installation.

Can you clarify what you mean and resolve this seeming paradox?

In order for you and your team to never rely on transient local state (either in the cloud or your own computer), we "start from scratch".

However, our process of starting from scratch is actually faster than running `npm install` on your own computer in many cases.

As an example, I've found myself getting into the habit of using `now` instead of `localhost`.

This doesn't address the poster's issue: If you reinstall every time, the results won't always be the same (not that I personally hold this as a big issue, I'd consider it on the programmer to freeze their package.json)

I think it's "reproducible" in the sense that it starts from scratch every time, rather than sometimes starting from scratch, and other times starting with a pre-populated node_modules. If you want actual versioning reproducibility, you'll need to put an npm-shrinkwrap.json in your root.

I see. They shouldn’t use the word “reproducible” then, because something is either reproducible or it’s not.

If they just mean, “We ignore everything but your package.json to generate a deploy,” say that, don’t mis-use the word “reproducible.”

(Heroku, for example, has put a lot of effort into making deploying to their platform actually, truly, really-the-same-years-into-the-future reproducible. `npm install`, especially without shrinkwrap -- and `now` doesn't seem to be using shrinkwrap -- will never get there.)

I’m still not 100% if I get what they are doing or not.

After all, I need some sort of index.js or dist/foo.js in my package, and if they aren’t using git or anything, then isn’t this by definition happening based on transient local state (my local files at `now`-time)?

> `now` doesn't seem to be using shrinkwrap

They aren't? I haven't tried a deployment, but was hoping/assuming they'd upload a shrinkwrap along with everything else and that it would drive the install as per usual.

> I’m still not 100% if I get what they are doing or not.

I think their angle is to lower barriers to entry close to zero for cloud deployments, and thus drain a shallow ocean. "Shallow" in the sense that there are devs who are interested, but maybe not interested enough to buy into terminology like "dynos" or "cartridges" or "lambdas". "Ocean" in the sense that there are (supposedly) quite a few of these people.

I’m potentially one of those people, at least for personal projects and such. But I also need to understand what the hell I’m getting into before I make the leap.

I haven’t kept my personal site up with no linkrot for the past 10 years by making technology choices on a whim, you know?

So the deploys do not depends on npm infrastructure at all?

Reply on news.ycombinator.com