skip to content
all writing
no. 01 2 min read

radar only reports, on purpose

A tool that updates your dependencies for you is a tool you stop reading. This one tells you what is wrong and leaves the fixing to you.

josh donnell maintains radar

Every team I have worked with has a dependency bot. Every one of them also has a column of its pull requests that nobody has opened in a month. The bot did its job. The humans stopped doing theirs, because the bot made it feel like someone else's.

When I started radar, I made one rule before writing any code: it never touches your lock files. It scans Composer and npm, stores a snapshot, and tells you what is vulnerable, outdated or abandoned. That is all.

The radar dashboard: a health score of 43 out of 100, twelve packages, and four vulnerabilities listed by severity
The radar dashboard on a fixture app. Every finding comes with the command to fix it, and nothing runs until you do.

read-only is a feature

Installing it is one package and one command. The scan runs on demand, or nightly at 02:00 with onOneServer() so a multi-server deploy only scans once.

terminal 
$ composer require joshdonnell/radar
$ php artisan radar:install
$ php artisan radar:scan

Outside your local machine, the dashboard sits behind a gate you define. I would rather you write one line of policy than trust a default you never read.

app/Providers/AppServiceProvider.php 
use Illuminate\Support\Facades\Gate;

public function boot(): void
{
    // Only admins see dependency health in production.
    Gate::define(
        'viewRadar',
        fn ($user = null): bool => $user?->is_admin === true,
    );
}

If a tool fixes things without asking, you stop knowing what is in your app.

  • Report everything, change nothing.
  • Give the exact command, and let a human run it.
  • Make the nightly scan boring enough to trust.