I can think of 3: 1. Semver.
Pushing out a critical bug fix can be a liability if every project that consumes that module, and all its parents must be updated. This is exacerbated by node.js/npm's default behavior of deeply nested static dependencies. 2. Private Forks of Public Modules Ability to publish private versions of public modules. Recently we wanted a unique fix to forever-agent[1] which request depends upon. You could achieve this via npm_shrinkwrap (I believe), but that would need to be done on a per-project basis, whereas being able to publish a private forked version, while still consuming the public request module is a little more elegant because now everyone at your company who depends upon request, doesn't need to remember to include an npm_shrinkwrap. 3. Speed I don't know if the debate over whether you should checkin your dependencies and run `npm rebuild` on deploy, or use npm_shrinkwrap, or prebuild and deploy a tar is a solved issue or not, but it definitely seems the easiest way to deploy is to deploy your application code, run npm install (w/ or w/o a shrinkwrap) and go on your merry way. A private npm repo will speed this process up significantly, especially as your dependency list grows (which can be partially mitigated by breaking your application into several services). Cheers, Adam [1] https://github.com/mikeal/forever-agent On Fri, Aug 2, 2013 at 4:48 AM, Santiago Gimeno <[email protected]>wrote: > Hi, > > Probably a dumb question, but what are the advantages of having a private > npm repository over getting the modules from your private git repository > with npm using: "my_module": "git+ssh://git@my_repo:my_module.git#version" > ? > > Cheers, > > Santi > > > 2013/8/2 Adam Crabtree <[email protected]> > >> Miroslav, >> >> Thanks for the link to npm-proxy. I didn't realize that project existed. >> >> Osher, >> >> There is Nodejitsu's new "Enterprise Private npm" initiative, though I'm >> not sure if it offers the same private/public fallback of npm-proxy, which >> to me is the key feature for smaller companies not wanting to (like you >> said) replicate the whole npm repo. I would opine that main npm repo can >> get very slow at times (though usually not), so there is the additional >> benefit of speed wrt hosting a replica even if it all seems rather wasteful. >> >> I personally find myself wanting to publish forks of public modules to a >> private repo to avoid the need for npm_shrinkwrap for nested dependencies >> needing fixes. >> >> Cheers, >> Adam >> >> >> >> >> On Thu, Aug 1, 2013 at 12:06 AM, Miroslav Bajtoš <[email protected] >> > wrote: >> >>> Hi Osher, >>> >>> There are multiple options for setting up a private repo, unfortunately >>> none of them is ideal. >>> >>> 1. Create a replica of npmjs.org >>> 2. Setup your own registry using CouchDB and npmjs code, but don't >>> replicate the public registry >>> 3. Use a different registry server, e.g. reggie [1] mentioned by Andy >>> >>> Let's check your requirements: >>> >>> we don't want to host an entire replica of the npm (which is *HUGE *these >>>> days, and growing) >>>> i.e - the private replica should hold only our packages, the rest can >>>> come from the public repo >>> >>> >>> This is true for options 2 and 3. >>> >>> publishing should direct to our repo >>> >>> >>> This can be achieved with all three options. Either add the following >>> line to your package.json >>> "publishConfig": { "registry": "http://private/registry/url"; } >>> or use the reggie CLI client for publishing the packages. >>> >>> install should take our packages from our repo, and public packages from >>>> the global repo >>> >>> >>> The npm client does not support multiple repositories at the moment, >>> even though there are plans to get this implemented in the next few >>> weeks/months. Unless you have a replica of npmjs.org (option 1), you >>> must use different way for installing and referencing packages from public >>> and private repository. >>> >>> With couchdb-based registry, you can use absolute URL to the tarball of >>> the desired version. (This means you can't specify a fuzzy version like >>> ~0.5.2.) >>> >>> Node reggie implements several kinds of package URLs to support fuzzy >>> version specification. See project README [1] for more details. >>> >>> It may be possible to overcome this limitation by sticking an npm proxy >>> [2] in front of your private registry. >>> >>> users in local repo should match users in global repo >>> >>> >>> You will get this for free with npmjs.or replica. >>> >>> If its possible to setup CouchDB replication in such way that only users >>> are replicated, then you can get this functionality with non-replicated >>> CouchDB-based registry too. >>> >>> Reggie does not implement authentication and authorization at the moment >>> - it will happily accept (and ignore) whatever credentials are sent by the >>> npm client. >>> >>> I hope you will find this helpful, don't hesitate to ask if there is >>> anything else not clear. >>> >>> Miroslav >>> >>> [1] https://github.com/mbrevoort/node-reggie >>> [2] https://npmjs.org/package/npm-proxy >>> >>> >>> On Wednesday, July 31, 2013 6:51:21 PM UTC+2, Osher E wrote: >>> >>>> oups, sorry for the resending, >>>> but I forgot to mention another problem we had - >>>> >>>> - users in local repo should match users in global repo >>>> >>>> it sounds so simple, but we had problems with that >>>> (all the part with npm adduser and stuff) >>>> >>>> >>>> On Wed, Jul 31, 2013 at 7:36 PM, Osher El-Netanany >>>> <[email protected]>wrote: >>>> >>>>> Hi all, >>>>> >>>>> 'ok, this is kind'a embarrassing a little, >>>>> we've tried few times in few ways but still did not get it right: >>>>> >>>>> - we're trying to set a local npm repo for our packages >>>>> - we don't want to host an entire replica of the npm (which is *HUGE >>>>> *these days, and growing) >>>>> i.e - the private replica should hold only our packages, the rest >>>>> can come from the public repo >>>>> - publishing should direct to our repo >>>>> - install should take our packages from our repo, and public >>>>> packages from the global repo >>>>> >>>>> What's the best way to do it? >>>>> What's the best contemporary tutorial/doc/explanation about it on the >>>>> web? >>>>> >>>>> Thanks... >>>>> Don >>>>> >>>> >>>> -- >>> -- >>> 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. >>> >>> >>> >> >> >> >> -- >> Better a little with righteousness >> than much gain with injustice. >> Proverbs 16:8 >> >> -- >> -- >> 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. >> >> >> > > -- > -- > 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. > > > -- Better a little with righteousness than much gain with injustice. Proverbs 16:8 -- -- 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.
