> On Oct 10, 2011, at October 10, 20115:30 PM, Isaac Schlueter wrote:

>> Yes, this is normal.

>> You can avoid this situation if you want by installing mkdirp at the
>> top level first, as a dependency of your program, and then install the
>> other packages.

> If you do this and a dependency needs a different version it'll still be installed right?

>> What's the weird result you got?

>> On Mon, Oct 10, 2011 at 09:13, Dean Landolt <d...@deanlandolt.com> wrote:

>>> On Mon, Oct 10, 2011 at 10:14 AM, rogerz <rogerz.zh...@gmail.com> wrote:

>>>> mkdirp is required by lots of packages. Is it normal to have multiple
>>>> copy of it under each module?

>>>> ├─┬ expr...@2.4.7
>>>> │ ├── conn...@1.7.1
>>>> │ ├── m...@1.2.4
>>>> │ ├── mkd...@0.0.7
>>>> │ └── q...@0.3.1
>>>> ├─┬ j...@0.16.2
>>>> │ ├── comman...@0.1.0
>>>> │ └── mkd...@0.0.7
>>>> ├─┬ mongo...@2.3.0
>>>> │ ├── col...@0.5.0
>>>> │ ├── ho...@0.1.9
>>>> │ └── mong...@0.9.6-20
>>>> └─┬ sty...@0.17.0
>>>>  ├── cs...@0.2.0
>>>>  ├── gr...@1.1.0
>>>>  └── mkd...@0.0.7

>>>> I've tried to install mkdirp manually before other packages but get a
>>>> more weird result. What do people usually do with this issue? Leaving
>>>> the packages repeated? This is not cool.

>>> Is it really that bad? How much space is each instance of mkdirp eating up?
>>> I could see it being a problem on embedded devices, but that's about it.
>>> Regardless, to fix all you have to do is use symlinks to point all copies of
>>> mkdirp to one global location. This is pretty easy to do by hand, but should
>>> be pretty easy to script too. Obviously the best thing would be if this
>>> could be done without burdening npm with added complexity. And this really
>>> wouldn't be all that different than an `npm link` so it should play nice
>>> with npm's design (although windows has an f'ed up flaw in its symlinks
>>> where rimrafing follows links and wipes out their targets).
>>> I could imagine npm growing a local registry allowing you to map
>>> package@versions to canonical fs locations but as Isaac noted when he
>>> originally addressed this tradeoff in the design: is it really that bad to
>>> duplicate these packages? Really?