skott: graph your project to find cycles and dead files

A project graph, and everything built on top of it

skott is described as a minimalist developer tool that efficiently generates directed graphs from your JavaScript, TypeScript or Node.js project. The interesting part is what sits on top of that graph. The tool automatically collects metadata such as file size, third-party dependencies and builtin dependencies, detects circular dependencies, finds unused npm dependencies, and exposes primitives so you can build tools that rely on graph data structures. The README puts the philosophy plainly, that anything that can be implemented using graphs can be implemented using skott. That claim is what separates it from a one-off dead code finder, because the same traversal machinery that finds a cycle can answer which files an incoming change affects. The display side is broad. There is an embedded interactive web application, terminal based views such as a file tree and a graph view, and static output in .svg, .png, .md and .json, with the visualisation modes available both from the CLI and programmatically through the API.

Resolution that ignores the module system

The mechanism that makes the graph work across projects is stated plainly in the README: skott does not rely on module systems for path resolution, it will resolve require and import no matter the configuration. The supported file list is given as .js, .jsx, .cjs, .mjs, .ts and .tsx, so ECMAScript and CommonJS are both covered, along with JSX and TSX. TypeScript path aliases are supported as well, which matters because an alias is the usual reason a naive resolver gives up. There is a second layer for larger codebases, since skott works with any custom dependency resolver, which the README calls useful for specific monorepo integrations where module identifiers need to be mapped to a specific workspace package. That is a small API surface but an important one, since a monorepo where the same package name exists in several workspaces cannot be analysed correctly without it.

The unused dependency list has a stated blind spot

Two of the headline features are about dead weight in the project. skott detects unused source code files, so you can eliminate dead code by finding files that are not imported anywhere else in the graph, and it detects unused npm third-party dependencies. The second feature comes with a caveat the README does not soften, which is that all unused devDependencies are not guaranteed to be detected, as depcheck also only provides analysis for a set of supported libraries such as eslint, karma and mocha. That is a genuinely useful admission, because it marks the boundary of the analysis rather than letting you assume a clean bill of health. In practice, a devDependency such as a formatter, a test runner or a type checker is often referenced in configuration or in a script rather than imported from source code, and a tool that only walks import statements cannot see it. The realistic use of the output is a shortlist for a human to check, not an automated prune of the manifest.

The CLI and the API return the same graph

skott can be used through its command line or through its JavaScript API, and the README shows both taking the same options. The command line form runs a full analysis of the current working directory, with a display mode, third-party tracking and an ignore pattern for test files.

The API call takes the same shape as an options object, and the returned functions are the entry points to everything the CLI can show:

import skott from "skott";

const {getStructure, getWorkspace, findUnusedDependencies, useGraph} = await skott({

    dependencyTracking: {
        builtin: false,
        thirdParty: true,
        typeOnly: true
    }
});

One constraint matters before you build on it, since it decides how you package your own tooling: the API is currently published as ESM only.

Narrowing the analysis when the graph gets heavy

Because the graph can become heavy on large codebases, skott gives you three ways to shrink the scope, and they are best taken in order. The first is to point it at a sub folder, either with the command line flag:

skott --cwd=packages/skott 

or with the cwd option in the API, which is the same thing in code. The second is to give it an entrypoint file, which makes it strictly traverse the graph starting from that entrypoint and discard all other files that are not part of the graph, which is the right mode for a package with a clear public surface. The third is incremental mode, which is marked experimental, and in it skott only analyzes files that were modified or added since the last run. The README also documents a watch mode that updates the graph when file changes are detected, and it works with every display mode. File tree traversal respects ignore patterns and Git ignored files, so .gitignore files are honoured without extra configuration.

A graph API aimed at tools you write yourself

The exposed primitives are the part that turns a visualiser into a platform. The API includes deep parent and child dependency traversals using DFS and BFS algorithms, and metadata collection per traversed node, covering file size and dependencies. The useGraph() function hands back a set of operations including findCircularDependencies and collectFilesDependencies alongside the traversal API, so a consumer can ask specifically for the dependencies of a given node rather than walking the whole structure. The README names the intended use, affected and incremental patterns, and points out that skott knows precisely and deeply the dependencies for each graph node, which is what a build tool needs in order to know what to rebuild. The circular dependency search can also be given a maximum depth, which is a practical concession to the fact that on a large graph an unbounded search is the thing that hangs. Static output includes raw JSON as well as mermaid-js diagrams in .svg, .png and .md generated directly from the CLI.

A pnpm monorepo with changesets

The repository layout shows how the project is built. It is a pnpm workspace, with pnpm-lock.yaml, pnpm-workspace.yaml, a packages directory and an apps directory, and the root manifest pins [email protected] as its package manager. Versioning and publishing run through changesets, with the root scripts calling the changeset version and publish commands, and the changesets cli and a changelog generator in the development dependencies. The package itself is published to npm as skott, and the documentation lives in the package rather than at the repository root, with the README pointing to the skott package level readme for the complete documentation and to a separate file for API samples. The licence is MIT. On maintenance, the last push was on 2026-09-11 and the repository is not archived, with the recent tags [email protected] on 2026-09-11, [email protected] on 2026-03-31 and [email protected] on 2026-03-17, so the patch releases come at a steady clip within a single minor line.

Editorial conclusion

skott fits a team that wants a machine readable map of a JavaScript or TypeScript codebase to drive its own tooling, since the graph primitives, the traversal API and the JSON output are exposed rather than locked inside a visualiser, and it fits monorepos that need a custom dependency resolver. It is the wrong choice if you need a settled answer on unused devDependencies, because the README itself points at the same limitation depcheck has, and it is a poor fit for a small project where a text editor search is faster. Before you adopt it, run it on one package with the entrypoint option to see how the graph shapes up, and treat the unused dependency list as a starting point for review rather than a list to delete from.

Frequently asked questions

Official sources

1. antoine-coulon/skott on GitHub
2. Issues
3. License: MIT
4. README
5. Releases