Skip to main content
forge radar is landing in the v0.19 line. This guide describes how it fits the existing dependency-currency discipline; run forge --help to confirm availability in your installed version.
One of Forge’s engineering rules is: before adding a dependency, verify the current best option from live sources, and prefer what the project already uses. forge radar makes the standing state of your dependencies visible so that rule has data behind it.

The idea: currency rings

forge radar groups the project’s dependencies into concentric currency rings by how current each one is — from up-to-date at the center out to stale or drifting at the edge. Reading the rings is a fast way to answer “what have we let drift?” without auditing every package by hand.

Where the dependency list comes from

Radar builds on the same manifest reading that powers forge stack, which detects the repo’s real stack from its dependency manifests:
Because detection is data-driven and fail-safe across ecosystems (package.json, pyproject.toml, go.mod, Cargo.toml, Gemfile, composer.json, pom.xml / build.gradle, *.csproj), radar can reason about currency for the same set of manifests stack understands.

Using it in the loop

1

Check the rings before a dependency change

Run forge radar to see which dependencies are already drifting before you add or bump one.
2

Prefer what's already current

If a capable, current dependency already sits in an inner ring, reuse it rather than adding a new one — the smallest change that fits wins.
3

Record the decision

When you do bump or replace a dependency, record why:
so a future session reads the choice instead of re-litigating it.
Radar reports currency; it does not upgrade for you. Treat its rings as advisory input to a human decision — and verify any bump with the repo’s real tests (forge verify) before calling it done.

Verify the change

After a dependency bump, run the Quality gates — forge verify and forge precommit.