100Developer tools

Snowbros Atlas

A deterministic static-analysis engine for JavaScript, TypeScript and Python, written in Rust.

Role: Author. Built under SNOWBROS.
Year: 2026
Status: v0.4, open source. Published to npm, crates.io, Homebrew and the VS Code Marketplace, with x64 and arm64 binaries for three platforms.
Stack: Rust, Tree-sitter, petgraph, LSP, VS Code API, SARIF

The Snowbros Atlas product page: 'Same code in. Same findings out.' beside a terminal running sb analyze.

built-in rules: 23
cold run on axios, 431 files: ~230 ms
after a one-file change, 500-file repo: ~34 ms
tests across a 19-crate Rust workspace: 340+

(57) Abstract

Atlas maps a whole project, every import, export, env var and framework boundary, and reports only the problems it can prove. Same codebase in, same findings out, every time.

Background

Per-file linters see one file at a time. The expensive bugs live between files: a circular import that survives for years, a server-only module that leaks into a client bundle, a dependency nobody uses anymore. Atlas is built for that layer. It runs alongside ESLint or Biome, not instead of them.

Drawings

FIG. 1A run from the README. The finding names the rule, the confidence, and the import chain that proves it.
FIG. 2Crate architecture. Dependencies flow one way, from a shared vocabulary up to the CLI and the language server.
FIG. 3sb analyze --format html writes a self-contained report: a health scorecard, then every finding with its evidence.

sb analyze

$ sb analyze
Snowbros Atlas · analyze
  root: /work/acme-web
  files scanned: 512
  cache: 0 reused, 512 parsed
  frameworks: Next.js 15.1.0, React 19.0.0

HIGH Server-only module imported by a client component [next/server-only-in-client]
  at src/components/Dashboard.tsx · confidence: certain
    - import chain: Dashboard.tsx → lib/metrics.ts → lib/db.ts ("server-only")

✗ 1 finding(s): 1 High
◆ health: 92/100 (security 100, architecture 85, …)

FIG. 1A run from the README. The finding names the rule, the confidence, and the import chain that proves it.

FIG. 2Crate architecture. Dependencies flow one way, from a shared vocabulary up to the CLI and the language server.

Snowbros Atlas HTML report: health scores followed by six findings with evidence. — **FIG. 3**sb analyze --format html writes a self-contained report: a health scorecard, then every finding with its evidence.

Detailed description

One IR for every language

A 19-crate Rust workspace, about 17k lines, parses with Tree-sitter and lowers JavaScript, TypeScript and Python into one shared semantic IR. A rule is either language-agnostic or scoped to a language family in one place, never an if-language branch inside a detector. The same large-function rule runs on a Next.js app and on FastAPI.

Evidence or silence

Every finding carries the chain that produced it and a confidence level: certain, likely or possible. Anything the resolver cannot prove is reported as unresolved. It is never guessed.

A cache that cannot change the answer

An incremental cache keyed on xxh3 hashes, file times and a config fingerprint lets a warm run skip work. Tests prove the warm output is byte-identical to a cold run, so the cache can only save time.

Fixes that refuse to guess

sb fix plans byte-span edits first, then applies them only if the file still matches what the analysis saw. A file that changed in between is skipped, not clobbered. Fixes are idempotent.

$ sb fix --dry-run
○ would apply 2 fix(es):
  package.json remove unused dependency "left-pad" [deps/unused-dependency]
  .env remove unused variable OLD_API_URL [env/unused-env-var]

Wherever the developer already is

One binary installs as snowbros and sb: analyze, watch, fix, graph, model, explain. sb lsp serves diagnostics to any LSP editor, a TypeScript VS Code extension wraps it, and SARIF 2.1.0 output feeds GitHub code scanning behind a --ci gate. Five CI workflows release it to npm, crates.io, Homebrew and x64/arm64 binaries for three platforms.

What is claimed is:

1.
A static analyzer whose findings are a pure function of the code and its configuration.
2.
The analyzer of claim 1, wherein each finding carries the import chain or cycle members that prove it.
3.
The analyzer of claim 1, wherein a warm cached run produces output byte-identical to a cold run.
4.
The analyzer of claim 1, wherein JavaScript, TypeScript and Python share one semantic IR and one set of language-neutral rules.
5.
The analyzer of claim 2, further comprising an auto-fix step that skips any file changed since analysis.