Arkit draws the architecture of a codebase and lets you commit it

Static analysis turned into a picture

Arkit is described as a static analysis tool that automatically generates visual architecture diagrams from your codebase, making it easy to understand and communicate software structure, and the tag line is more specific, visualising JavaScript, TypeScript and Flow codebases as meaningful and committable architecture diagrams. The word committable is the interesting one, because it distinguishes this from a diagram you screenshot for a slide. The feature list starts with automatic code analysis across JavaScript, TypeScript, Flow, Vue and Nuxt source files, then component grouping, which associates source files with configured architectural components, and dependency visualization, which renders the grouped components and a dependency graph including Node.js modules. The point of grouping is that a dependency graph of a real project is unreadable, so the tool lets you declare which files belong to which layer and draws the layers.

Java is a hard requirement, and it is there for PlantUML

The system dependencies section is the one to read before anything else. Arkit requires a Java Runtime Environment 8 or higher for diagram generation, with installation instructions for each platform, Adoptium on Windows, brew install openjdk on macOS and sudo apt-get install default-jre on Linux, and a note that you can verify it with java -version. The reason is in the requirements section. Arkit uses local PlantUML conversion via Java to generate SVG and PNG diagrams, and the consequences are spelled out as a list of properties. No external web service calls, because all conversion happens locally. Your code stays private, because no data is sent over the network. It works offline. And it requires Java, which you must have installed. If Java is missing the tool prints an error with installation instructions, so the failure mode is a message rather than a stack trace.

GraphViz is optional, WebAssembly is the default

GraphViz is handled differently from Java, and it is worth understanding why. By default Arkit uses the @hpcc-js/wasm-graphviz package, a WebAssembly port of GraphViz, which has no system dependencies, and it is used automatically if it is installed:

npm install @hpcc-js/wasm-graphviz

If that package is not available, Arkit falls back to the system GraphViz, which you install from graphviz.org on Windows, with brew install graphviz on macOS and with sudo apt-get install graphviz on Linux. The one case where you need nothing at all is the PlantUML output, since the documentation notes that you can generate .puml files without any system dependencies by using the --output puml option. So there are two independent escape hatches, the puml format for text output with no runtime dependency, and the WebAssembly GraphViz package for a local renderer without a system install. Java is the only requirement that cannot be dodged for raster or vector output.

Running it and configuring it

The quick start is one command with no installation, which analyzes the current directory and produces an arkit.svg:

# Run arkit instantly without installation
npx arkit

As a development dependency it is installed with npm install arkit --save-dev or yarn add arkit --dev. The usage examples cover the real cases, from a source folder with an explicit output, to entry files and the PlantUML format, to excluding paths and raising the log level, to writing both an SVG and a PNG:

# Generate SVG diagram from source folder
npx arkit src/ -o arkit.svg

# Specify entry files and output format (PlantUML)
npx arkit -f src/main.js -o puml

# Enable debugging and exclude specific paths
LEVEL=info npx arkit -e "node_modules,test,dist,coverage" -o puml

# Generate both SVG and PNG
npx arkit -o arkit.svg && npx arkit -o arkit.png

The flags are the ones you would expect from a tool that has to work on somebody else's repository. The working directory, the config file path, the output path or type, the file patterns to place first in the graph, and the patterns to exclude, whose default already covers test, tests, dist, coverage and the test, spec and minified file patterns. The help output lists all of them:

user@machine:~$ npx arkit --help
arkit [directory]

Options:
  -d, --directory  Working directory                              [default: "."]
  -c, --config     Config file path (json or js)         [default: "arkit.json"]
  -o, --output     Output path or type (svg, png or puml) [default: "arkit.svg"]
  -f, --first      File patterns to be first in the graph               [string]
  -e, --exclude    File patterns to exclude from the graph
        [default: "test,tests,dist,coverage,**/*.test.*,**/*.spec.*,**/*.min.*"]
  -h, --help       Show help                                           [boolean]
  -v, --version    Show version number                                 [boolean]

The configuration can also live in a JSON file, a JS module or the package.json of the project, and the advanced configuration is shipped with a JSON schema, which is published at arkit.pro/schema.json and is what gives you autocomplete and validation in an editor.

Grouping is what makes the output readable

The configuration file is where the value of the tool is decided, because the diagram is only as good as the grouping. The schema is small and the shape is clear, with exclude patterns at the top, a list of components each with a type and a set of patterns, and an output list where each output has a path and a list of groups:

{
  "$schema": "https://arkit.pro/schema.json",
  "excludePatterns": ["test/**", "tests/**", "**/*.test.*", "**/*.spec.*"],
  "components": [
    {
      "type": "Dependency",
      "patterns": ["node_modules/*"]
    },
    {
      "type": "Component",
      "patterns": ["**/*.ts", "**/*.tsx"]
    }
  ],

The groups then decide the order and the membership of what is drawn, with a group marked first placed at the top of the graph and other groups referring to components by type. The package.json of a project can carry the same configuration, and the repository demonstrates exactly that by generating a diagram of Arkit itself from its own package.json. That self-documentation is the pattern the tool is nudging you towards, since the configuration is versioned with the code and the diagram is regenerated when the code changes.

Practical advice from the documentation

Two pieces of advice in the documentation are worth passing on as they are. The first is about scale. If your project is huge and the first diagrams look messy, it is better to generate them per feature, per architectural layer and so on, which is the same conclusion the configuration model reaches, that you get a useful diagram by narrowing the scope rather than by improving the renderer. The second is about workflow. Once you are satisfied with the results, add the arkit command to your build script, so that it will keep your architecture diagrams up to date. The feature list calls this CI/CD integration and real-time updates, and the reason it works is that the diagram is a build artifact rather than a document somebody has to remember to refresh.

The project around the tool

The repository is a TypeScript project with a few notable files. The package file shows the build as prettier, then a tsc compile, then a schema build with typescript-json-schema that generates schema.json with the published schema URL as its id. The tests are jest with coverage, the lint step is eslint, and husky is wired to the prepare script. The engines field requires Node 20 or newer, the binary is index.js, and the package version is 2.1.0. Two planning documents at the top level are telling, an ESM migration plan and a Mermaid migration plan, so the project is between output formats, and the presence of an llms.txt file is a nod to the same audience the tool serves. The top level also has an arkit.svg and a worldstar.svg, which are the diagrams of the tool itself. The project is MIT licensed, the repository is not archived, the last push was on 2026-10-18, and no GitHub releases are published, so the npm version is the artefact to depend on.

Editorial conclusion

Arkit fits a team that wants a committed picture of its own structure, since the PlantUML output is text that survives a diff and the SVG is regenerated in CI, and it fits anyone who cannot send source code to a third party service because all conversion is local. It does not fit a project without a Java runtime, since SVG and PNG generation goes through a local PlantUML conversion, and it does not fit a large repository with no grouping rules, because the documentation itself warns that a huge project with no configuration produces a messy first diagram. Before you adopt it, define the components in arkit.json so the output is readable, and if you only want text output use the puml format so you do not need Java at all.

Frequently asked questions

Official sources

1. dyatko/arkit on GitHub
2. Issues
3. License: MIT
4. Project website
5. README