On Wed, Mar 19, 2014 at 7:32 AM, Patrick Debois <[email protected]> wrote:
> Hi group, > > I'd like to get some feedback on the following flow of publishing nodejs > apps in a continuous delivery mode: > Are you trying to "deliver" modules? Or "deploy" applications? It's a bit unclear what your end product is. If your users are people using a service you develop internally then your deployment process should probably focus on dev -> staging -> prod type workflow with an emphasis on reproducibility (ie, checking in node_modules). If your users are devs who will be `npm install`ing your modules then it might make sense to shift the focus away from reproducibility and more towards broadness of test environments. You'll want to test several combinations of accepted dependency versions and on multiple platforms. If you want reproducibility here, you'll need to be bundling your deps (which can be done in CI, no need to check in node_modules) and pay the perpetual tax of revving each time a dependency releases a security patch. Shrinkwrapping would be similar but _slightly_ more fragile. But if you're that paranoid about versions you may as well go the extra step and bundle since the overhead is pretty much the same. Shrinkwrapping may be useful for capturing dependency combinations for testing and archiving test results. On Fri, Mar 21, 2014 at 1:26 AM, greelgorke <[email protected]> wrote: > > 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. > I think this is a far more reasonable approach than a private npm registry if all you need is to be able to do is `npm install` a package. If you're getting into large numbers of inter-dependent packages with a mix of private, public, prerelease, etc. then you may not have any choice but to use a private registry. At StrongLoop we're using the `npm pack` + http approach with some custom install tooling at the moment, but we're looking at whether involving a private registry would work better for us. On Sat, Mar 22, 2014 at 12:52 PM, Alex Kocharin <[email protected]> wrote: > > Keeping node_modules in git is extremely noisy. I strongly believe that > git should not have anything machine-generated in it. If something is > generated automatically, it should not be in git. Since modules are > installed using npm from an external source, they should not be in git. > Alex, how do you feel about machine generated scaffolding code being in version control? Since npm installs dependencies into the app's tree, to me it really blurs the line between external dependencies and managed code. I think keeping node_modules in git makes sense for something like a web app that you maintain and deploy, but not for standalone npm modules that get published to npmjs.org. ~Ryan -- http://twitter.com/rmgraham -- -- 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.
