this ist not a problem, at least not a big one. npm rebuild triggers the binary re-compilation without re-installing
Am Samstag, 22. März 2014 13:32:47 UTC+1 schrieb Filipe Deschamps: > > The problem of checking in modules is when a module compile binaries and > you have developers working on different OS, like Ubuntu and OSX. > > On Thursday, March 20, 2014 10:57:10 AM UTC-3, Peter Rust wrote: >> >> 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.
