Find hermit packages
The problem
Every codebase accumulates code nobody talks about. A helper extracted "for later" that nothing ended up importing. A folder left behind when its callers were rewritten. A utility that quietly does its own thing and depends on nothing. On the dependency graph, its package or source-folder node floats free of the connected architecture. It is easy to miss precisely because there is no edge to draw your eye.
Why it matters
A node with no visible dependencies is telling you something, and it is rarely "nothing." It may be dead code you are still compiling and testing, an unfinished refactor, an entry point wired through configuration or reflection, or a genuinely self-contained utility. Each is a decision waiting to be made, but only if you can see the node in the first place. Hermits are usually cheap to explain and disproportionately confusing to leave unexplained, because every reader who finds one has to work out why it exists.
Where to start
Begin with the Topology Graph with isolated nodes shown.
Step by step
- Open the Topology Graph.
Run AtlasArc from the Tools menu or the AtlasArc toolbar icon. The graph shows the currently visible modules, JVM packages, or TypeScript source folders; directed edges show the analyzed dependencies between them.
- Show the isolated packages.
Turn the "Hide isolated" filter OFF. Most sessions keep it on to reduce noise, which is exactly why hermits stay invisible. With it off, every visible node with no edges floats free of the connected graph.
- Clear other filters so nothing is artificially hidden.
Starting this workflow clears reference, fan, and cycle filters, pauses Exclusions and deep package roll-up, and turns Hide isolated off. It keeps your current Root, and your exclusion list remains intact for later. If you configure the view manually instead, use Reset before scoping the audit. A node can look isolated only because filtering hid its edges.
- Scope a large audit with Root.
For a large project, right-click the module, package, or source folder you want to inspect and choose Set as Root. Hermits are easier to judge in context; an isolated utility node reads very differently from one stranded in the middle of your domain structure.
- Reveal the chosen subtree, not the whole project.
Right-click the selected module, package, or source folder and choose Expand completely so collapsed children cannot conceal hermit candidates. This expands only that subtree; avoid project-wide Expand All unless the whole-project audit is deliberate.
- Classify each hermit, then act.
For each floating node, decide what it is. Check reflective loading, framework or configuration wiring, and generated entry points before removing anything. Delete confirmed dead code. Reconnect or finish an unfinished refactor. Keep and document an externally wired entry point. Consider promoting a genuinely self-contained utility to a shared library or internal module where its independence is a feature, not an accident. Navigate to the code directly from the node before making the call.
Interpreting results
Not every hermit is dead. A package or source folder may be a deliberately decoupled utility, a plugin loaded reflectively, or an entry point wired through configuration the static graph cannot see, so confirm before you delete. The signal is not "isolated therefore useless"; it is "isolated therefore unexplained." Resolve the explanation: either the node earns its independence and you document why, or it does not and you remove it. A codebase with zero unexplained hermits is one where every node has a reason to exist that the next reader can reconstruct.
Export & share
Use Export → Snapshot as PNG with Hide isolated off to capture the scoped graph including the floating nodes, so a code-review or cleanup ticket shows exactly what is stranded and where.