Feature request: Filter based on React (or other) Component imports

[forivall]

Context

I'm trying to use static analysis to determine the possible component tree within a large application, but omit all of the util / data / etc. cruft.

Expected Behavior

Example:

enum.ts

export enum MyEnum {
  A = 1;
  B = 2;

a.tsx

import * as React from 'react'
import { MyEnum } from './enum'
import B from './b'
export default function A = (props) => <div key={MyEnum.A}><B /></div>

b.tsx

import * as React from 'react'
import { MyEnum } from './enum'
export default function B = (props) => <span>This is B = {MyEnum.B}</span>

with this option, the graph would be like

digraph {
  "a.ts" -> "b.ts"
}

and ignore the enum import

An even better use case would be to trace the actual component name, but that's a lot harder to decipher.

Current Behavior

This feature doesn't exist, although it's similar to tsPreCompilationDeps

Possible Solution

Analyse the code, and only count it as a dep if the import is used as a component in JSX. (This wouldn't cover all component uses, but it's most of them)

Considered alternatives

Alternative is to use storybook, and then use react devtools to look at the tree, but that takes a lot of setup, and the thing i'm looking at is stuff we want to remove.

Other alternative i just thought of is to include only component files -- ie, only .tsx files. i'll be doing that instead for now.

[forivall]

yup, my alternative to --include-only just tsx worked for my needs. feel free to close if this isn't something you'd pursue

[forivall]

Or actually, another implementation possiblity is to filter only files that depend on react -- there's a couple .tsx files in my project that don't actually import react. -- better solution to this problem -- add an option like --focus, that allows external ... looking at config typings

yeah, adding a new option to IIncludeOnlyType like jsx: boolean or requires: string | string[] would do the trick.

[forivall]

Actually, i'd probably still want to do this, but spin it out to a separate module, and pull in dependency-cruiser's rendering internals. My solution in #344 wasn't perfect, because it still runs afoul of the index.tsx issue, which just re-exports other dependencies, which lead to this mess (rendered using xdot, as it was the only piece of existing software that highlights the edges on hover -- something else i'd want to make, a better visualized dot output. alas.)

[sverweij]

• To get highlight-on hover you can put the output from dot through depcruise-wrap-stream-in-html e.g.:

depcruise -v -T dot packages | dot -T svg | depruise-wrap-stream-in-html | browser

• If your graph is not too big (<~150 nodes) orthogonal routing might help with readability (dot -Gsplines=ortho -T svg or put splines: 'ortho' in the theme in the .dependency-cruiser-config might help)
• Finally, with theming it's possible to color nodes and edges based on (a.o.) path names - see e.g.
  the graph and config for react here.

(On of the things on the wish list: have incoming and outgoing dependencies highlighted when hovering over nodes.)

[forivall]

Perfect! Thanks for mentioning it, I was looking around for something like that to wrap the svg output, and ended up taking longer looking for something than it would have taken to write something quick and dirty

also, ortho definitely does help with my graph. thanks for the tip!

[sverweij]

@forivall the fact you couldn't find this quick enough is a clear sign the doc needs to get a different information-archi (and maybe --init's game needs to be up'ed as well). Also you're not the first one bumping into this.

Thanks for the PR in any case!

[forivall]

Yeah, adding a mention to --init would definitely help, as that's the main thing i was working off of to get myself acquainted with the project.