envinfo turns a bug report into a machine inventory

The version question that opens every bug thread

envinfo exists to answer a narrow question quickly: which versions of what is installed on this machine. The README frames it with the phrases developers actually type when something fails, including "command not found" and "what version of command are you running?", and it points at the request that appears in every GitHub issue template asking for the browser version, the Node.js version, the operating system and the programming language. The tool is aimed at maintainers of libraries and frameworks who spend time on that request, and at contributors who would rather paste one block than answer four questions. It does not debug anything. It has no configuration file, no plugin system and no state. It inspects the local machine and reports what it finds, which is why it fits well as a first step in a bug report and fits badly as a diagnostic tool.

Categories, helpers and promises behind the report

The report is organised into categories, and the documented CLI output groups them as System, Binaries, Managers, Utilities, Servers, Virtualization, SDKs, IDEs, Languages, Databases, Browsers, npmPackages and npmGlobalPackages. Each entry is probed by a helper, and the README states that every helper is exported so you can use a single piece rather than the whole report. Those helpers return a promise that resolves to an array of values, and the documented shape is name, version and path, so a helper for a binary gives you the path as well as the number. The programmatic entry point takes a configuration object listing which categories and which items you want, and returns a promise resolving to a string that can be formatted as plain text, yaml, json or markdown. Underneath, the package ships a webpack build of the src/ directory, exposes dist/envinfo.js as the main entry and dist/cli.js as the console binary.

Installing envinfo and running the CLI once

There are two ways to get a report, and both are one line. The global install gives you the envinfo command everywhere; the npx form runs the same CLI without touching your global package directory, which is the better choice inside a container or a CI job where you do not want to install anything. Add it as a project dependency instead if you plan to call it from application code.

npm install -g envinfo || yarn global add envinfo

npm install envinfo || yarn add envinfo

The bare command prints the full category listing you saw in the README, including the path of each binary it found, for example Node, Yarn, npm, Watchman and the package managers Cargo, CocoaPods, Gradle, Homebrew, Maven, pip, RubyGems. If a binary is missing, the question is whether the report should say so out loud or leave the gap, and that is what the showNotFound option controls on the programmatic path.

Calling envinfo.run with a configuration object

The library path is the one to use when the report is generated automatically, for example inside a doctor command in your own CLI or in a bug reporter in a desktop app. You pass a configuration object that maps categories to the items you care about, plus an options object, and you get a promise back. The documented example asks for a slice of System, Binaries and Browsers, adds two npm packages by name, and passes the json and showNotFound options, then logs the result.

import envinfo from 'envinfo';

envinfo.run(
    {
        System: ['OS', 'CPU'],
        Binaries: ['Node', 'Yarn', 'npm'],
        Browsers: ['Chrome', 'Firefox', 'Safari'],
        npmPackages: ['styled-components', 'babel-plugin-styled-components'],
    },
    { json: true, showNotFound: true }
).then(env => console.log(env));

With json enabled the resolved value is a structured object rather than a text block, so you can pick out the fields you want instead of pasting everything.

npm package entries carry the wanted and installed range side by side

The npmPackages category is the one that earns its place in a report. Each listed package shows the version range your manifest asks for and the version that is actually resolved, for example styled-components with a caret range and the concrete installed version, and it uses a Not Found marker when a package is declared but absent. That distinction catches a whole category of confusing failures, where a fresh install behaves differently from a workstation that has been accumulating packages for two years. The same applies to npmGlobalPackages, which lists the globally installed packages without a range comparison. The sample output in the README also includes packages such as jest, react and solidarity, which illustrates the point that the tool reports the dependency tree as it stands rather than what a lockfile would produce.

One helper instead of the whole report

When the full inventory is noise, the exported helpers give you a single fact. The README shows requiring the package and awaiting a helper, then indexing into the resolved array, where the documented values are name, version and path, for example a Node entry of a version string and the path to the binary. This is the difference between running envinfo as a report generator and using it as a small library of version probes, and it is the mode that fits a setup script that wants to warn only when the Node version is too old.

const envinfo = require('envinfo');

// each helper returns a promise
const node = await envinfo.helpers.getNodeInfo();

// The promises resolve to an array of values: ["Name", "Version", "Path"]
// e.g. ["Node", "10.9.0", "/usr/local/bin/node"]

console.log(`Node: ${node[1]} - ${node[2]}`); // "Node: 10.9.0 - ~/.nvm/versions/node/v8.14.0/bin/node"

What the report cannot tell you, and where a custom checklist wins

Two limits are worth stating plainly. First, envinfo records versions and paths, not configuration, so it will happily report the Node version while telling you nothing about which registry is configured, which proxy is set, or why a binary is not on the PATH. The reported path is often the real clue in a shell that differs from the one you assumed, so the tool is a good starting point and a poor conclusion. Second, the category list is fixed and finite, and the README does not document a way to add your own probe, so a team that needs to record a private internal tool version has to write a checklist around the exported helpers instead. The alternative to the full report is therefore not another package but a small script that calls envinfo.helpers for exactly the fields your issue template asks about, and pastes only those lines.

MIT licensed, with a release line that keeps moving

The licence is MIT, which is permissive enough that the code can be read, vendored into an internal CLI, modified and redistributed with attribution and no warranty. There is no copyleft obligation to publish changes, so a team can fold the helpers into a proprietary doctor command without opening that code. The repository is not archived and the last push was on 2026-10-07. The release history shows v7.22.0 on 2026-06-03, v7.21.0 on 2025-11-27 and v7.20.0 on 2025-11-02, so tagged versions land irregularly across the year rather than on a fixed cadence. The package manifest declares support for node versions from 4 upward, while the toolchain in the same file is modern, with webpack for the build, jest for tests, oxlint for linting, prettier for formatting and a type test that compiles against TypeScript 6 and TypeScript 7. The project also ships its own type definitions, and the README states that a separate @types/envinfo package is no longer needed.

Editorial conclusion

Teams with an issue template that keeps asking for versions will get immediate value from envinfo, since one command replaces a long back and forth about Node, browser and SDK versions. It is the wrong tool if you need to diagnose why a tool misbehaves rather than record which version it is, and it is a poor fit for environments where a full inventory is itself a disclosure risk, because the report includes binary paths and the home directory. Before adopting it, decide whether the default category list is what you want, check how your team will paste the output, and pin the version you install, since the newest tagged release is v7.22.0 from 2026-06-03 while the last push was on 2026-10-07.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. tabrindle/envinfo on GitHub