Allow filtering of full modules tree

[Swaagie]

The goal of this PR is enable dependencyFilter to filter all modules rather than just a single level from the tree. While trying to be backwards compatible with current implementations as much as possible. Backwards compatibility can't be achieved for those who use a filter with includeNpm.

Use cases are for example filtering all scoped dependencies, especially if those scoped dependencies depend on other modules within the same scope. Imagine a monorepo where composites are derived from a set of base components within the same monorepo. Technically Madge could be run for each dependency but getting the full import tree would be cumbersome that way.

There are two alternatives to this solution and I'm happy to change the code towards the desired direction.

• config.dependencyFilter overrides the default filter implementation. This provides flexibility but will not be backwards compatible. Anyone using a filter today would need to include the defaults. The default filter could easily be exposed for re-use within custom filters. Personally this would have my preference as its much easier to document, code and keep consistent.
• additional option to include the entire modules tree rather than a single level, or perhaps repurpose includeNpm to allow for a certain depth of n with a default of 1.

[PabloLION]

Hi @Swaagie , thanks for the hard work. But it seems we are having a problems here

rc problem

As reported by

• How to configure dependencyFilter in .madgerc #259
  Current dependencyFilter option is passing a function by rc file which both

1. unmeet the rc standard
2. has no effect

We might need to rework on this. I don't have a mature idea about the implementation of how to pass a JS function via CLI/rc file.

Based on my very limited edification, this is about how to serialize the function and it seems this is the best way to do it?

New ideas

An alternative worth mentioning is to use RegExp like we did with excludeRegExp, we can filter the npm modules with npmFiles, npmInclude, npmExclude (or npmFilesRegExp, npmIncludeRegExp, npmExcludeRegExp) like #353 (formerly #220) to line up with the tsconfig convention.

Any opinion would be appreciated. @kamiazya @fdc-viktor-luft @pahen
@eltonio450(does this achieve the idea of npmWhitelist in #281?)

[PabloLION]

closed due to inactivity. Welcome to create another PR if needed