@Brian: i think what you describe isn't npm's issue. if you have a deployment beyond simple apps, then you need another tool and another process that fits it. shrinkwrap helps you with managing dependency versions, not dependencies. if you have need that level of deploymant safety, take maven or ant or whatever you like, let your CI server do pull the repo to your target, do the npm install/rebuild and pack it as tar or debian package or whatever, put it into your private repo. even java projects use rpm or dpkg for production installations. not maven
Am Mittwoch, 6. November 2013 12:34:28 UTC+1 schrieb Brian Lalor: > > On Nov 5, 2013, at 11:25 PM, Will <[email protected] <javascript:>> wrote: > > For the Googlers of the future that reach this thread: the answer depends > on the nature of your project. > > - *Do** track* `node_modules` in your repo if you are deploying an app. > > > This is not as solved a problem as Mikeal and others would like to think. > From an operations perspective, doing *any* compilation on deploy is a > terrible idea. It’s a HORRIBLE idea. It’s a product of developers who are > ignorant of deploying applications repeatably and at scale. The only thing > you should be deploying is binary packages, compiled for the target you’re > deploying to, preferably in a system package (deb, rpm). Your production > systems shouldn’t even *have* gcc on them, and that’s required if you have > to run “npm rebuild” for a deployment step. > > npm’s dependency resolution and loading model is excellent, but if “npm > shrinkwrap” — the only tool in the suite that’s supposed to help solve the > floating transitive dependency problem — doesn’t do the job, then it needs > to be fixed. Checking dependencies into source control is a hack. > > npm’s model has greatly simplified the way I do deployments. Ruby’s gems > suck, Python’s less onerous but still kind of a pain. It’s amusing and > painful to watch the Fedora folks try to bend node dependency model to fit > their archaic packaging standards (do yourself a favor and just don’t use > anything node-related from EPEL). npm needs to adopt the Maven central > repository’s roach motel contract: packages check in, but they never check > out. This combined with a reliable way to lock down dependency versions > and and compile-once binary deployment packages means never having to run > “npm install” or “npm rebuild” on a production box, no matter how old your > application is. > > -- > Brian Lalor > [email protected] <javascript:> > > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
