On Thu, Jan 5, 2012 at 9:16 AM, Aaron <[email protected]> wrote: > I am not sure this is the best idea as it flattens the "namespace" modules can > exist in. For example, I have a few projects that have a module > installed locally > with "npm install node-cron@latest" and I have a node-cron in > /usr/local/lib that is at an older version ( npm install -g node-cron )..
Assuming that /usr/local/lib/node_modules comes after the local install path in the lookup list, your locally installed module should have precedence, right? That was my intent, if the patch doesn't do that, I'll be happy to modify it. The interesting thing is, the final entry in the lookup list should resolve to /usr/local/lib/node, which doesn't even contain modules (only a bunch of python scripts under wafadmin). > This patch would probably ( I haven't tested yet ) cause some confusion. > > Is there any reason that "npm link <module>" is not sufficient? Haven't tried that, but from reading the documentation, it would appear fix the issue. However, in my opinion, that should be an unnecessary step. Maybe I'm just used to practically all other interpreters (ruby, python, perl, etc.) where globally installed modules can be loaded directly. :) > I will test it to verify my "namespace" flattening hypothesis. OK. If it does cause problems, is there another approach that would work better (besides npm link)? Jeremy
