Evidence first.
Certainty has limits.

What happens when you analyze a package?

1. Resolve a version. The npm registry identifies a concrete version for your package name or version range.
2. Build the dependency graph. We resolve runtime dependencies with package scripts disabled. We inspect up to 26 packages and traverse up to four dependency levels. The dependency resolver may do additional work before those inspection limits apply.
3. Inspect archives. We extract package files and inspect up to 160 files for the root scan and 45 per dependency. File-size and parser limits can reduce coverage.
4. Classify signals. Manifest entry points and detected APIs are compared against coarse capability profiles for each runtime.
5. Save the result. A completed analysis creates a public report snapshot. Opening a saved report only reads that snapshot; it never refreshes or runs a scan automatically.

Supported runtime profiles

• Browser
• Node.js
• Bun
• Deno
• Cloudflare Workers
• Vercel Edge
• Vite SSR

These are broad profiles, not certifications for particular runtime versions. Compatibility flags, permissions, bundlers, platforms, and deployment settings can change real behavior. Vite SSR is treated as a Node-based server environment; browser SSR is not applicable.

Four dimensions, with source evidence

Import

Entry points and module formats that may affect loading a package.

Execute

Signals such as native addons and dynamic code that may affect execution.

APIs

Detected runtime-specific APIs, including selected Node built-ins.

SSR

Signals relevant to server-side rendering in the chosen profile.

Findings identify the package chain, file, reason, confidence, and approximate reachability. Package code is never evaluated or executed.

Source excerpts and suggested next steps

New analyses save up to five lines from the published package around the first detected occurrence of a signal, with line and column numbers. Long lines are clipped. These locations refer to published files, which may be compiled or minified, rather than source maps. Manifest and binary findings may have no source excerpt.

Suggested next steps come from rules for the detected signal and runtime, with checks for optional dependencies and uncertain reachability. They are guidance, not verified patches. Regex-based checks can match comments or strings; inspect the excerpt and test the affected operation in your deployment before changing code.

Older saved reports remain unchanged and may lack excerpts or remediation. Requesting a new analysis can create an updated report while preserving the original link.

What the labels and score mean

• Likely compatible: no concerning blocker detected in the inspected scope. This is not verified support.
• Potential issue: a signal needs review; it may be unreachable, optional, or handled by your build.
• Likely incompatible: a stronger conflicting signal was found in a selected direct entry.
• Unknown: inspection is incomplete or the available evidence is insufficient.

The score is a heuristic summary of dimension statuses, not a percentage probability or benchmark. New reports withhold the score when inspection is incomplete or a finding has unresolved runtime support. Missing evidence is not a numerical compatibility penalty. Known conflicts remain visible even when the score is withheld.

How runtime support affects findings

Supported filesystem, subprocess, eval, and CommonJS loader features do not count as conflicts on Node-based profiles. Native binary inspection looks for Node-API symbols without loading the addon. Bun and Deno support Node-API, but an unidentified addon ABI stays unresolved. A build manifest or filename alone does not establish that native code is required at runtime.

Deno assessments refer to its CLI, with the required permissions and local node_modules for native addons. Workers filesystem and selected Node APIs depend on compatibility settings and the operation used. Reports state these assumptions. Package engine declarations are shown as constraints; no exact target version is selected or checked yet, and declarations cannot cancel an unsupported feature.

Known limitations

• No runtime tests, sandbox execution, or verification against deployed applications.
• Transitive reachability, tree shaking, conditional code, generated files, export subpaths, and computed imports are only approximated or partially handled.
• Optional dependencies are included with lower-confidence warnings; platform selection is not resolved. Peer and development dependencies are not scanned as normal runtime dependencies.
• Native addons and CommonJS behavior vary by runtime version, platform, flags, and tooling.
• Parser failures, unavailable archives, size limits, and graph caps can hide issues. Both false positives and false negatives are possible.

Confirm consequential findings in your exact runtime and deployment configuration before choosing or rejecting a package.

Versions, freshness, and public reports

The analysis cache lasts seven days. Saved report links preserve the original package version, analysis date, and findings beyond that cache lifetime. Older snapshots may reflect older rules or capability assumptions. A fresh analysis can produce a new report; existing report URLs do not change.

Reports cover public npm packages and are publicly readable. Never submit credentials or private registry URLs. Refreshes happen only when someone explicitly requests an analysis, subject to API limits.