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

> 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?