Thanks for the explanation! As for hosted private repo's - that's looking cool but don't think I'd use it since then still I've to push all modules to the cloud before building. I want to keep things local.
Putting full paths in the requires, really don't want that - but NODE_PATH comes to the rescue there. Hmm... What I'm doing now is using npm pack to wrap up a specific release of a module, store that in a "module" directory and access it through http://localhost.. for which I wrote a tiny script that hosts all files in a directory on a port. Not entirely happy about that yet, also since the packaging has to be done manually. Will think about it some more. Thanks again! Antoine On Fri, Jul 12, 2013 at 9:22 AM, greelgorke <[email protected]> wrote: > In addition to point 2: You can use in both project require('myLib') > without path, just define NODE_PATH to the folder. but still you have to > manage to different versions of the same lib. the git-dep is a better > sollution here, i guess. > > Am Donnerstag, 11. Juli 2013 02:26:40 UTC+2 schrieb Marco Rogers: > >> @greelgorke is right that npm link is meant for development and not >> deployment. But I think I understand your problem. You have a single module >> repo, myLib, that you want to share between projects. I assume it's an >> internally developed module and not suitable for publishing to the public >> npm repository. That's fine. But you want to manage independent versions of >> this module that can be used in site1 and site2. This is reasonable. It >> just sounds like you're getting stuck on finding a recommended workflow >> that doesn't feel like overkill. Here are some suggestions. >> >> 1: Ideally you would want a private npm repository. You can push your >> internal myLib there and then reference it in your package.json as normal. >> When you do an npm install for your deployment, you would also specify the >> repository to look in, and npm should try your internal private repository >> first. This has been a request for a while, and there are a few options. I >> believe iriscouch is going to start hosting private repos, >> https://www.irisnpm.**com/ <https://www.irisnpm.com/>. And I believe >> strongloop is offering to support private repos via their slnode fork. >> >> Setting up and maintaining a private repo may still be too much effort >> what you're trying to accomplish though. But it's something to be aware of. >> >> 2. Managing internal modules does not have to go through npm. You can >> just put the module directly in your project build for site1 and site2. You >> can put myLib in a lib/ folder or something. Then reference it by a >> relative path. site1/lib/myLib - > require('./lib/myLib'). >> >> Another thing to consider is that you can still use git locally to manage >> versions and branches of myLib. Just just use a local repo. That'll help >> you manage the different versions of myLib that need to go with site1 and >> site2. Not need to get a separate git server involved :) >> >> I hope this helps outline a few different ways to look at this problem. >> You can pick whatever matches up best with your needs. >> >> :Marco >> >> On Monday, July 8, 2013 7:26:19 AM UTC-7, Antoine wrote: >>> >>> Thinking more about it, shouldn't this just work? >>> >>> - run "npm cache add ." from the myLib dir (make sure you've got the >>> proper version set in package.json). It will "install" the package in the >>> cache >>> >>> - specify "myLib": "<version>" as a normal dependency in your project's >>> package.json >>> >>> - in your project run npm install myLib >>> >>> >>> Now this does not work, but gives an error that the package is not in >>> the npm registry. But hey, it's in the cache - why is it checking the >>> registry in the first place? I would not expect that since I'm directly >>> specifying a version which is in the cache. >>> >>> npm version 1.2.32 >>> node version 0.10.12 >>> >>> >>> Antoine >>> >>> >>> >>> >>> >>> >>> >>> >>> On Mon, Jul 8, 2013 at 3:23 PM, Antoine van Wel <[email protected]>wrote: >>> >>>> I don't have a good answer to your question; I think we are struggling >>>> with the same problem. >>>> >>>> IMHO "npm link" is not suitable for (y)our use case. What you really >>>> want to do is put "myLib" in your package.json dependencies, and specify a >>>> version, and specify where to fetch it from - and preferably in such a way >>>> that this works in both development flows and production flows. >>>> >>>> So looking at the options from there.. Seems like you can specify git >>>> repo's directly in your dependencies. Well I've got my repositories locally >>>> on my drive, not running any git servers though, so what now? Setting up a >>>> local git server to access these repositories? That seems a bit overkill to >>>> me. Setting up your own npm repository? Also feels like overkill. >>>> >>>> Thinking out loud: I just want to store these modules in a path, >>>> perhaps say "npm install <destination-repo> and point to that path, control >>>> the path via environment variables, perhaps similar to "maven" repositories >>>> as used in the Java world. Multiple versions of the same package need to be >>>> stored in the same structure. >>>> >>>> Thoughts anyone? >>>> >>>> >>>> Antoine >>>> >>>> >>>> On Mon, Jul 8, 2013 at 2:09 PM, Maxim Yefremov <[email protected]>wrote: >>>> >>>>> I have site1 and site2 on one server, they both depend on one library >>>>> myLib via npm link. >>>>> >>>>> I changed myLib for site2 so it might be buggy for site1. How to >>>>> avoid it? >>>>> >>>>> I want to use separate versions of myLib for site1 and site2. >>>>> >>>>> But when I do npm link command for myLib on server then site1 and >>>>> site2 both use the same version of myLib >>>>> >>>>> -- >>>>> -- >>>>> Job Board: http://jobs.nodejs.org/ >>>>> Posting guidelines: https://github.com/joyent/** >>>>> node/wiki/Mailing-List-**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<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<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. > > > -- -- 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.
