Tested ( amd64 ). The order of precedence is indeed working like you said.
OK. On Thu, Jan 5, 2012 at 10:43 AM, Jeremy Evans <[email protected]> wrote: > 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
