shrinkwrap was useless before, but since npm disallows to override specific versions, you get the guarantee, that the published thing is the same all time. unfortunately npm still does not prevent the forced unpublish, so it is possible that the package is gone. but you can prevent that by a private registry mirror.
btw. you dont need private npm for handling your own internal artefacts. your ci server can npm package the artefacts and pout it on secure webserver. nopm can install from simple http urls. Am Donnerstag, 20. März 2014 14:57:10 UTC+1 schrieb Peter Rust: > > I'm not really experienced in this area, but some in the node community > say that checking in your dependencies is better than using "npm > shrinkwrap": http://www.futurealoof.com/posts/nodemodules-in-git.html. > The Golang community has the same stance. > > Here's one relevant paragraph from the above article: > > Doesn’t checking in node_modules create a lot of noise in the source tree > that isn’t related to my app? > > No, you’re wrong, this code is used by your app, it’s part of your app, > pretending it’s not will get you in to trouble. You depend on other > people’s code and they are just as likely to write new bugs as you are, > probably more so. Checking all of that code in to source control gives you > a way to audit every line that ever changed in your application. It allows > you to use $ git bisect locally and be ensured that it’s the same as in > production and that every machine in production is identical. No more > tracking down unknown changes in dependencies, all the changes, in every > line, are viewable in source control. > > That said, I'm sure some (many?) disagree and prefer to use "npm > shrinkwrap". > > -- peter > > On Wednesday, March 19, 2014 7:32:34 AM UTC-7, Patrick Debois wrote: >> >> Hi group, >> >> I'd like to get some feedback on the following flow of publishing nodejs >> apps in a continuous delivery mode: >> >> The flow I imagine is described below. I'm wondering if: >> >> - it makes sense to use an internal npm as build artefact repository >> - it annoys me that I have to change the version of the package.json >> (the source) to change the version of the artifact >> - every commit will result in 2 extra build commits >> - I could use another artefact repository like create rpm/deb >> packages or use 2 separate npm internal registraties (one for test , one >> for prod) >> >> Sorry if this seems trivial , but I could only find example to deploy to >> prod but didn't really care on a reusable build artefacts. >> I'd love to hear how you've solved this dance :) >> >> Patrick >> ------------------------------- >> Steps in the nodejs continuous delivery mode: >> Check-in: >> >> 1. developer checks in his code for the app >> 2. post-commit hook to run some basic unit tests >> 3. does push to git >> 4. git commit triggers build >> >> Build stage: >> >> 1. in build stage, I'd run grunt tasks to create consolidated >> javascript files etc... and run unit tests >> 2. once finished and succesful, I want to archive the build >> 3. then I'd want to publish it to my artefact repo >> 1. in increase the version with prerelease tags (using >> grunt-release), so it's not installed by @latest >> 2. run `npm shrinkwrap` to lockdown the versions >> 4. commit the version change, new build js & shrinkwrap back to git >> (with a tag) but carefully avoid a new trigger of the CI with [ci skip] >> 5. i publish this version to npm using `npm publish --tag rc` (actually >> using publishConfig to avoid updating >> lates<https://github.com/npm/npm/issues/4837> >> t) >> 6. if success, go to next stage >> >> Integration testing: >> >> 1. deploy on a machine (using npm install myapp@rc) >> 2. run my integration tests >> 3. if success, go to next stage >> >> UAT testing: >> >> 1. deploy on a machine (using npm install myapp@rc) >> 2. run my integration tests >> 3. if success >> 1. increase version >> 2. `npm publish --tag` latest >> 3. commit the version change, new build js & shrinkwrap back to >> git (with a tag) but carefully avoid a new trigger of the CI with [ci >> skip] >> 4. if success, go to next stage >> >> Deployment: >> >> 1. now on each of the production do the loadbalancer dance >> 2. and run npm install@latest of the app. >> >> >> >> -- -- 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/d/optout.
