Feature request: Option to show full path to reachable and circular dependencies

I have a large codebase (angular application and shared libraries) that is somehow including a large external dependency into the core application. In this case the dependency is leaflet, but it could generally be any library I don’t want to end up in the core bundle. (I am using angular lazy loading to bring in sub-areas of the application)

What I would like to do is provide dependency-cruiser the application entry point file and then have it tell me both if and import {} from 'leaflet' is reachable from the base application but also if it is then tell me that dependency chain from the entry point onward that got to leaflet (ie. the list of all imports in order starting from the initial file).

I think I have a rule that will detect the reachability:

    {
            name: 'not-to-leaflet',
            comment: 'got leaflet',
            severity: 'error',
            from: {},
            to: {
               "path": "^leaflet$",
               "reachable": true
            }
        },

But it ends up being triggered on many modules and I can’t find a way to have it simply tell me the path that got there from the initial entrypoint file I gave dependency-cruiser.

Note: in my specific case I don’t needs all the paths that get there, just one is enough. Because after I remove that one, then if there is another I would use the script to tell me that one as well.

Is there a way to do this type of thing and see the full dependency chain?

Note: This would also be very useful when used to track down circular dependencies. On a large code base, the current system is nearly impossible for me to trace through and try to find the actual path that I need to break to fix the circular imports.

[sverweij]

hi @jomi-se I’ve done a few load tests on react and I’m getting similar results - it’s just as fast as 8.2.0, 8.3.0-beta-1 and 8.3.0-beta-4 (on average 71s over 10 runs (after 2 warmups) - 5774 modules, 12818 dependencies, with 6 rules on reachability). Surprising, but apparently the optimisation in the BFS algorithm that was in there until 8.3.0-beta-4 wasn’t that optimal itself…

As to why sub-dependencies also get flagged - in your example I bet there’s also four database-files-not-reachable-from-info-ts violations for the <from-matching-file>.info.ts, each for modules it can transitively reach in the <to-matching-directory>

  warn no-info-to-db: src/naughty.info.js → src/db/two.js
      src/naughty.info.js →
      src/in.js →
      src/between.js →
      src/db/index.js →
      src/db/one.js →
      src/db/two.js
  warn no-info-to-db: src/naughty.info.js → src/db/one.js
      src/naughty.info.js →
      src/in.js →
      src/between.js →
      src/db/index.js →
      src/db/one.js
  warn no-info-to-db: src/naughty.info.js → src/db/index.js
      src/naughty.info.js →
      src/in.js →
      src/between.js →
      src/db/index.js

I do understand the need to summarise these a bit (like with the cycles that are repeated for each module in the cycle) or to find the first via culprit, I’ll leave that for a future feature. (Thanks for voicing that concern b.t.w. - it’s feedback like this that helps a lot in improving the tool.)

B.t.w. there’s a summarising (‘collapsing’) feature in the dot and archi reporters (see below) already that might (1) helpful in getting a bit of overview (2) (note to self) be useful to port over/ move to other parts of dependency-cruiser:

[sverweij]

@jomi-se dependency-cruiser@8.3.0-beta-4 is less bare bones now and shows the from and to and makes the difference between ‘regular’ violations and ‘transitive’ ones more clear (by showing (via via) on the latter - can later be replaced with the whole path between them).

In the terminal:

In the html report: