@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/. 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]<javascript:>
> > 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]<javascript:>
>> > 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
>>> You received this message because you are subscribed to the Google
>>> Groups "nodejs" group.
>>> To post to this group, send email to [email protected]<javascript:>
>>> To unsubscribe from this group, send email to
>>> [email protected] <javascript:>
>>> 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] <javascript:>.
>>> 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.


Reply via email to