Added a depsDir option which allows for checking nested dependencies

[jneurock]

I need the ability to check nested dependencies, e.g., a Bower package's dependencies that are critically important but aren't specified in my project's own bower.json file.

I added depsDir so I could create a configuration that read my dependency's bower.json file but checked my project's bower_components directory. If depsDir is falsey, packageDir is used instead (which is what is used now).

I also updated README to include a blurb about depsDir and another blurb about checkGitUrls, which I found very useful but was missing from the list of options.

[mgol]

Thanks for noticing the checkGitUrls option was undocumented, I can't believe I've missed it! I've landed that change & released 0.9.2.

As for the depsDir feature, it seems to me to be a little cumbersome. To use it as you described you basically need to create a separate configuration for each dependency that has sub-dependencies to be able, right? That requires a large number of invocations of check-dependencies to check everything.

That said, this will become a problem when npm@3 gets released anyway as it will dedupe dependencies by default so I'll need to tackle it somehow. And if you wanted to write a module that would use check-dependencies to check everything recursively, you'd need check-dependencies to support the option you proposed here. :) So this might not be a bad idea.

Could you say how exactly would you use this feature? Would you write a wrapper module that would perform recursive checks or just do everything manually?

(BTW, I was thinking that if we allowed to pass custom depsDir, packageJsonName & depsJsonName this module would be general enough that people could use it even for officially unsupported package managers like component.)

I may be mostly unavailable for the next 1.5 weeks so don't get discouraged by my potential silence in the next days. I just don't want to rush it. :)

[jneurock]

Thanks for the quick reply. My use case is probably uncommon but I
absolutely need the functionality. I have a Bower package that extends
another (if you want to think of it that way). The base package has the
dependencies I want to check. Either way, check-dependencies doesn't do a
recursive check (I completely understand why) and I really need to make
sure those dependencies are good.

The way I'm using this is by calling check-dependencies three times: once
for npm, once for Bower and once for this particular Bower package. In the
3rd case, I used the packageDir option to have check-dependencies read my
Bower manifest from the package folder and depsDir to tell it to look for
those dependencies in the root folder. By default, check-dependencies is
looking in packageDir.

I wrapped all those calls with Q.all() so I got one promise back to work
with and it fully satisfies my use case.

I need to be able to do this; however, if my pull request doesn't line up
with where you want to go with the module, no worries. I can just use my
fork for this project.

Thanks!
Rocky

On Fri, Feb 27, 2015 at 11:11 AM, Michał Gołębiowski <
[email protected]> wrote:

Thanks for noticing the checkGitUrls option was undocumented, I can't
believe I've missed it! I've landed that change & released 0.9.2.

As for the depsDir feature, it seems to me to be a little cumbersome. To
use it as you described you basically need to create a separate
configuration for each dependency that has sub-dependencies to be able,
right? That requires a large number of invocations of check-dependencies
to check everything.

That said, this will become a problem when npm@3 gets released anyway as
it will dedupe dependencies by default so I'll need to tackle it somehow.
And if you wanted to write a module that would use check-dependencies to
check everything recursively, you'd need check-dependencies to support
the option you proposed here. :) So this might not be a bad idea.

Could you say how exactly would you use this feature? Would you write a
wrapper module that would perform recursive checks or just do everything
manually?

(BTW, I was thinking that if we allowed to pass custom depsDir,
packageJsonName & depsJsonName this module would be general enough that
people could use it even for officially unsupported package managers like
component.)

I may be mostly unavailable for the next 1.5 weeks so don't get
discouraged by my potential silence in the next days. I just don't want to
rush it. :)

—
Reply to this email directly or view it on GitHub
#8 (comment)
.