Skip to content

Latest commit

 

History

History
74 lines (60 loc) · 1.88 KB

readme.md

File metadata and controls

74 lines (60 loc) · 1.88 KB

elm-to-dot

Crawl an Elm project and produce a dependency graph in DOT.

$ npm install --global elm-to-dot
$ elm-to-dot --help
elm-to-dot [--include-external] <entry file>

usage

$ elm-to-dot src/Main.elm
digraph {
    rankdir=LR
    Main -> "Graph"
    Main -> "Native.File"
    Main -> "Native.Log"
}
$ elm-to-dot --include-external src/Main.elm
digraph {
    rankdir=LR
    "Graph" -> Dict
    "Graph" -> DotLang
    Main -> "Cli.Option"
    Main -> "Cli.OptionsParser"
    Main -> "Cli.Program"
    Main -> "Elm.Parser"
    Main -> "Elm.RawFile"
    Main -> "Elm.Syntax.Node"
    Main -> "Graph"
    Main -> "Json.Decode"
    Main -> "Native.File"
    Main -> "Native.Log"
    Main -> Parser
}

DOT can be fed into Graphviz to generate an SVG.

dependencies

I like this browser-based version of Graphviz, but I generated the dependency graph above like so.

$ elm-to-dot --include-external src/Main.elm \
    | dot -Tsvg \
    | svgo --input - \
    > dependency-graph.svg
  • dot is Graphviz. With the -Tsvg flag, it outputs an SVG.
  • svgo optimizes SVG files.

why?

I looked at elm-analyse and was surprised to find this CLI is largely written in Elm. However portions of the logic, like the file-gatherer, are written in TypeScript.

I wondered what it would be like to thinly wrap Node.js APIs in ports, allowing full filesystem access in Elm.

dev

$ npm install
$ npm run build
$ ./bin.js src/Main.elm
digraph {
    rankdir=LR
    Main -> "Graph"
    Main -> "Native.File"
    Main -> "Native.Log"
}