# \[ANN\] DependencyAtlas.jl—Explore Julia codebases as dependency graphs
**URL:** https://discourse.julialang.org/t/ann-dependencyatlas-jl-explore-julia-codebases-as-dependency-graphs/136317
**Category:** Package Announcements
**Tags:** package, staticlint, jet, reachabilityanalysis, static-analysis
**Created:** [March 21, 2026, 5:15am UTC](https://discourse.julialang.org/t/ann-dependencyatlas-jl-explore-julia-codebases-as-dependency-graphs/136317 "2026-03-21T05:15:43Z")
**Posts on this page:** 13
**Page:** 1
### Author:  [@karei](https://discourse.julialang.org/u/karei)
#### Post date: [March 21, 2026, 5:15am UTC](https://discourse.julialang.org/t/ann-dependencyatlas-jl-explore-julia-codebases-as-dependency-graphs/136317/1 "2026-03-21T05:15:43Z")
I’m happy to share DependencyAtlas.jl, a software package for turning Julia codebases into explorable dependency graphs.
DependencyAtlas focuses on _static and compiler-time source analysis_. It builds graph views from three engines: DepAtlasSource (source structure), StaticLint (semantic tooling), and JET (compiler-time evidence), so you can inspect a project as connected methods, files, and modules instead of reading it only as a directory tree.
Existing Julia packages already cover important parts of this space. StaticLint.jl, CSTParser.jl, and LanguageServer.jl support static and binding-aware analysis; JET.jl, SnoopCompile.jl, and Cthulhu.jl provide compiler-time and inference-oriented inspection; and ProfileView.jl, PProf.jl, and TraceFuns.jl target runtime behavior. The gap is that these tools usually expose only one layer of evidence at a time through editor, REPL, or profiler-specific workflows, rather than through a unified project-level dependency model. DependencyAtlas aims to fill that gap by combining source structure, semantic evidence, and compiler-time call evidence into a unified graph interface with method, file, and module views, bounded reachability, overload-site inspection, and source previews.
## What it does
DependencyAtlas can help you:
- explore method, file, and module dependency views
- inspect callers, callees, and bounded reachability
- preview source snippets and overload sites
- surface Base/stdlib and external package calls
## Why you may want it
When trying to understand a Julia codebase, you often want answers like:
- which functions or files call a particular method?
- what does the full call chain of a particular function look like?
- which files define the structure of this subsystem?
- what does the file dependency chain of the project look like?
Julia already has many excellent tooling components, but this software package brings these relationships together in one place through an interactive graph UI, making them easier to inspect as connected structure.
## Tech Stack
DependencyAtlas is a mixed-language project.
Backend: Julia
Frontend: TypeScript, React, Vite, React Flow, Tailwind CSS
Docs: Docusaurus, React, TypeScript
## Documentation
Website:
- [DependencyAtlas](https://karei.codeberg.page/DependencyAtlas.jl)
Repository:
- [karei/DependencyAtlas.jl - Codeberg.org](https://codeberg.org/karei/DependencyAtlas.jl)
## Screenshots
File dependency graph
Node path highlighting
Reachability mode (dark theme)
---
### Author:  [@dcelisgarza](https://discourse.julialang.org/u/dcelisgarza)
#### Post date: [March 21, 2026, 11:23am UTC](https://discourse.julialang.org/t/ann-dependencyatlas-jl-explore-julia-codebases-as-dependency-graphs/136317/2 "2026-03-21T11:23:27Z")
I’ve been wanting something like this for a while. Can’t wait to try it out.
---
### Author:  [@karei](https://discourse.julialang.org/u/karei)
#### Post date: [March 21, 2026, 11:30am UTC](https://discourse.julialang.org/t/ann-dependencyatlas-jl-explore-julia-codebases-as-dependency-graphs/136317/3 "2026-03-21T11:30:12Z")
Please give it a try! We look forward to hearing your feedback.
---
### Author:  [@juliohm](https://discourse.julialang.org/u/juliohm)
#### Post date: [March 21, 2026, 11:48am UTC](https://discourse.julialang.org/t/ann-dependencyatlas-jl-explore-julia-codebases-as-dependency-graphs/136317/4 "2026-03-21T11:48:25Z")
Is it possible to get VSCode integration? Or does anyone know an extension that builds similar graphs from Julia code?
---
### Author:  [@karei](https://discourse.julialang.org/u/karei)
#### Post date: [March 21, 2026, 12:21pm UTC](https://discourse.julialang.org/t/ann-dependencyatlas-jl-explore-julia-codebases-as-dependency-graphs/136317/5 "2026-03-21T12:21:17Z")
We could build it as a VS Code extension, which would enable nice editor integrations, such as clicking on a node and jumping directly to the corresponding source location.
However, it would not be a lightweight extension. It would still need to start a Julia runtime in the background to perform the analysis. There are also maintenance costs associated with that integration.
At the moment I do not have enough time or energy to maintain a VS Code extension on top of the current package, so it is not something I plan to take on right now. If someone is interested in building it, though, I would be very happy to review a PR.
---
### Author:  [@devel-chm](https://discourse.julialang.org/u/devel-chm)
#### Post date: [March 25, 2026, 3:43pm UTC](https://discourse.julialang.org/t/ann-dependencyatlas-jl-explore-julia-codebases-as-dependency-graphs/136317/6 "2026-03-25T15:43:26Z")
I tried installing on julia 1.10.9 with windows 11 and was not able to due to the
**julia** version requirement at 1.12.
Any chance for julia LTS support?
---
### Author:  [@karei](https://discourse.julialang.org/u/karei)
#### Post date: [March 25, 2026, 11:34pm UTC](https://discourse.julialang.org/t/ann-dependencyatlas-jl-explore-julia-codebases-as-dependency-graphs/136317/7 "2026-03-25T23:34:56Z")
Okay, I’ll try to relax it to julia v1.10 today.
Update: Hi devel-chm. I just resolved the Julia 1.10 compatibility issue. I tested the package on Julia v1.10.11 and made sure it works correctly there. Please try again on Julia 1.10.9. If you still run into any problems, feel free to leave another comment.
---
### Author:  [@cserteGT3](https://discourse.julialang.org/u/cserteGT3)
#### Post date: [March 26, 2026, 9:24am UTC](https://discourse.julialang.org/t/ann-dependencyatlas-jl-explore-julia-codebases-as-dependency-graphs/136317/8 "2026-03-26T09:24:06Z")
Is it intended to analyze packages only, or does it work on scripts as well? This was not clear to me going through quickly the docs.
I’ll give it a try anyways!
---
### Author:  [@karei](https://discourse.julialang.org/u/karei)
#### Post date: [March 26, 2026, 11:08am UTC](https://discourse.julialang.org/t/ann-dependencyatlas-jl-explore-julia-codebases-as-dependency-graphs/136317/9 "2026-03-26T11:08:16Z")
It works on scripts as well as packages.
At the moment, the analysis path can point either to _a package directory_ or to _a single Julia script_. If a script is provided, it is used as the entry file.
One thing to keep in mind is that the current project-root inference still walks upward looking for a `Project.toml`, so both package and script analysis may inherit context from an ancestor project if one exists. If no `Project.toml` is found in any parent directory, the file is currently treated as belonging to no module.
I have opened an [issue](https://codeberg.org/karei/DependencyAtlas.jl/issues/1) to track this more explicitly, including better GUI feedback and clearer documentation. I will update this soon.
Thank you for the question.
* * *
Update: Hi, @cserteGT3. This has been addressed.
The web UI now includes a separate `Project Root` input field. When you select a single file, that field is left empty by default, which means the file is analyzed without being placed inside any project context.
When you select a directory, DependencyAtlas still behaves as before and scans upward looking for `Project.toml`. The difference now is that the detected project root is shown explicitly in the `Project Root` field.
---
### Author:  [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)
#### Post date: [March 26, 2026, 4:55pm UTC](https://discourse.julialang.org/t/ann-dependencyatlas-jl-explore-julia-codebases-as-dependency-graphs/136317/10 "2026-03-26T16:55:19Z")
> [@karei](#):
>
> [ependencyAtlas.jl](https://juliaregistries.github.io/General/packages/redirect_to_repo/DependencyAtlas), a software package for turning Julia codebases into explorable depend
This happens on windows 11 with Julia 1.12.4
julia\> versioninfo()
Julia Version 1.12.4
Commit 01a2eadb04 (2026-01-06 16:56 UTC)
Build Info:
Official [https://julialang.org](https://julialang.org) release
Platform Info:
OS: Windows (x86\_64-w64-mingw32)
(@v1.12) pkg\> add [karei/DependencyAtlas.jl - Codeberg.org](https://codeberg.org/karei/DependencyAtlas.jl.git)
Updating git-repo `https://codeberg.org/karei/DependencyAtlas.jl.git`
Resolving package versions…
ERROR: Unsatisfiable requirements detected for package JSON [682c06a0]:
JSON [682c06a0] log:
├─possible versions are: 0.18.0 - 1.4.0 or uninstalled
├─restricted to versions 1 by DependencyAtlas [4fd80dc0], leaving only versions: 1.0.0 - 1.4.0
│ └─DependencyAtlas [4fd80dc0] log:
│ ├─possible versions are: 0.1.0 or uninstalled
│ └─DependencyAtlas [4fd80dc0] is fixed to version 0.1.0
└─restricted to versions 0.21 by P3109SignatureGenerator [a1b2c3d4] — no versions left
└─P3109SignatureGenerator [a1b2c3d4] log:
├─possible versions are: 2.0.0 or uninstalled
└─P3109SignatureGenerator [a1b2c3d4] is fixed to version 2.0.0
---
### Author:  [@karei](https://discourse.julialang.org/u/karei)
#### Post date: [March 26, 2026, 5:32pm UTC](https://discourse.julialang.org/t/ann-dependencyatlas-jl-explore-julia-codebases-as-dependency-graphs/136317/11 "2026-03-26T17:32:47Z")
Hi, thanks for the report.
This is a dependency conflict in your current environment. From the resolver output, `DependencyAtlas` requires `JSON 1.x`, while `P3109SignatureGenerator` restricts `JSON` to `0.21`, so Julia cannot satisfy both at the same time.
`JSON 0.21` belongs to the older pre-1.0 line. `JSON.jl` went through a significant transition at `1.0.0`, so I do not plan to make DependencyAtlas support both the old `0.21` line and the current `1.x` line at the same time. In general, the better fix is for the older package to relax or update its compat bounds if it can support newer `JSON` releases.
So the practical options are:
- install `DependencyAtlas` in a clean Julia environment, for example:
```julia
julia> ]
pkg> activate --temp
pkg> add https://codeberg.org/karei/DependencyAtlas.jl.git
```
- remove `P3109SignatureGenerator` from that environment if it is not needed there.
---
### Author:  [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)
#### Post date: [March 26, 2026, 5:38pm UTC](https://discourse.julialang.org/t/ann-dependencyatlas-jl-explore-julia-codebases-as-dependency-graphs/136317/12 "2026-03-26T17:38:40Z")
thanks for the quick response
---
### Author:  [@karei](https://discourse.julialang.org/u/karei)
#### Post date: [May 7, 2026, 10:39am UTC](https://discourse.julialang.org/t/ann-dependencyatlas-jl-explore-julia-codebases-as-dependency-graphs/136317/13 "2026-05-07T10:39:26Z")
# DependencyAtlas v1.0.0 is now available
I’m happy to share that DependencyAtlas.jl v1.0.0 is now available.
This is an important milestone for the project. With this release, DependencyAtlas is moving from an experimental tool into a more mature and stable package for day-to-day use. The main focus of v1.0.0 is faster analysis, a cleaner graph exploration workflow, and a more polished UI.
## Analysis now takes under two seconds
The main dependency graph is now built from `DepAtlasSource` only. `JET` is no longer part of the automatic whole-project analysis path, and is instead available as an on-demand method-level workflow. In practice, this makes regular analysis finish in under two seconds on the tested project.
## A rebuilt source analysis pipeline
`DepAtlasSource` has been rebuilt around a `JuliaSyntax`-first, fully typed internal pipeline. The active `StaticLint` path has been removed after moving the needed static-analysis coverage into `DepAtlasSource`, which also reduces backend overhead.
## Better graph layout and edge routing
Native ELK edge paths are now rendered directly, and the Graph Explorer has clearer controls for layout and edge routing. This should make larger dependency graphs much easier to read.
## A more comfortable graph workspace
The detail panel is now a draggable floating panel and can be pinned in place. Graph search has also been reorganized into separate `Search`, `Files to include`, and `Files to exclude` fields, which makes scoped exploration more convenient.
## Global color theme editing
The new `Colors` tab provides a global theme palette, so graph-wide UI colors can be tuned from one place.
## Open code directly from the graph
`Open in editor` and `Open with system default` are now available from the node right-click menu. Supported editors and IDEs include Cursor, VS Code, VSCodium, Sublime Text, PyCharm, and IntelliJ IDEA.
## On-demand JET View
You can now run `JET` from a selected method node and inspect the resulting pure `JET` call graph in a separate lower panel, without changing the main graph.
## Expanded documentation
The documentation has been expanded into a fuller docs site covering the architecture, protocol, API, export options, and common workflows.
There are also many smaller fixes around graph filtering, pagination, reachability depth, method preview targeting, Unicode identifiers, `where`-style definitions, and analysis of longer or more complex functions.
* * *
Thanks again to everyone who tried earlier versions and gave feedback. I’d be very happy to hear how v1.0.0 works on real Julia projects. I’m also collecting more graph color theme presets, so if you come up with a nice one, feel free to export it as JSON and open an issue in the repository.