npm link in deployment

[Maxim Yefremov]

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

[Antoine van Wel]

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

--
--
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 nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
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 nodejs+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Antoine van Wel]

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

  

[greelgorke]

npm pack creates a tarball from your lib, put the tarball on a webserver, where it can be downloaded, put the url to the tarball in the package.json of your site projects. you can name your tarball with different versions and reference it so.

npm link is meant for development not production usage.

if you want localy link your myLib to site1 for development, you can uninstall myLib localy and doe the link then.

[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/. 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

[Matt]

Where is myLib hosted? Assuming git, just use git repos in your dependencies and specify a branch for each one (via #branchname).

--

[Maxim Yefremov]

Thanx, Mat. myLib is hosted on bitbucked git repository. Allready starting to use git dependencies. It's little more time wasting in developement, but easy to deploy.

You received this message because you are subscribed to a topic in the Google Groups "nodejs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nodejs/OkFycQ4mLM4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to nodejs+un...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
С уважением,
Максим Ефремов

[greelgorke]

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.

[Antoine van Wel]

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

[greelgorke]

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.