we used a ci- server (jenkins) to do the job. it packed and uploaded to the host on every commit to the release branch. worked well.
Am Samstag, 13. Juli 2013 13:35:14 UTC+2 schrieb Antoine: > > 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]<javascript:> > > 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]<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.
