ESLint Config Inspector: visual flat config debugging

Why eslint/config-inspector targets flat-config debugging

ESLint Config Inspector addresses a specific configuration problem: a flat config may combine many entries, ignores, plugins, and overlapping rules, making its effective structure difficult to understand from source code alone. The tool is aimed at developers and maintainers who already use ESLint's flat configuration model and need a visual interface rather than another text-only configuration file. It does not replace ESLint's linting job. Its purpose is to expose and help explain the config, which makes it most relevant when diagnosing why rules apply to particular files or how configuration entries relate.

The project targets the current configuration file, `eslint.config.js`, rather than the older `.eslintrc` format. That boundary matters. A team with a flat config but complicated imports, generated entries, or long override structures has a plausible use case for this inspector. A team whose configuration still depends on `.eslintrc` cannot assume the tool understands it, because neither the README nor the package metadata claims support for that format. The narrow scope is also an advantage for evaluation: this is not a general dashboard for lint errors, test coverage, or editor diagnostics. It is a view of the ESLint configuration itself.

The repository's package metadata identifies the package as `@eslint/config-inspector` and declares ESLint as a peer dependency. Supported peer ranges are `^8.50.0`, `^9.0.0`, and `^10.0.0`. This means adoption is tied to compatibility with the project's installed ESLint major version. The package also declares a Node.js engine range of `^20.19.0 || ^22.13.0 || >=24`, so runtime compatibility should be checked before using the command in CI, older developer images, or container bases.

How the local config reaches the browser interface

The documented local flow begins with the command-line entry point and ends at a web interface on port 7777. The package exposes both `@eslint/config-inspector` and `eslint-config-inspector` as binaries, with each mapped to `./bin.mjs`. Based on the repository layout, the CLI and browser application are separate build outputs. The root package uses the `type` field set to `module`, and its build script runs both `nuxt build` and `tsdown`, indicating that Nuxt produces the application while the CLI is bundled separately.

The runtime dependency list adds detail to that architecture. `jiti` is present for loading JavaScript or TypeScript configuration content, `chokidar` is listed for file watching, and `devframe` supplies the development server, RPC transport, and static-build foundation described by the README. The app itself is based on Nuxt and Vue, with UnoCSS used for styling in attributify mode. The directory structure separates concerns into `app/`, `src/`, `shared/`, and `bin.mjs`, while `nuxt.config.ts`, `uno.config.ts`, and `tsdown.config.ts` contain the application and build configuration.

The README states that changes to the config file are updated automatically. That behavior makes the tool useful for hypothesis checking: edit `eslint.config.js`, wait for the automatic update, and inspect the changed representation in the browser. The documentation does not describe the exact inspection algorithm, serialization format, rule-matching model, or refresh interval, so those implementation details should not be assumed. It is safer to judge the interface by whether it presents the loaded configuration clearly and reflects edits.

Running eslint/config-inspector for the first inspection

No global installation is required for the basic documented workflow. From the project root containing `eslint.config.js`, run the package with `pnpx`. The `pnpx` command executes the package without adding it as a named dependency to the project. The README then directs the user to the local browser address, where the config can be viewed and changed for inspection.

pnpx @eslint/config-inspector

After the command starts, open `http://localhost:7777/`. That address is the documented local endpoint for viewing and interacting with the ESLint config. Make a small edit to `eslint.config.js` and check whether the browser reflects it. Automatic config updates are documented, but the README gives no timeout or failure message, so the visible result of the edit is the appropriate first check.

The CLI can also describe its supported options. This command does not require a second configuration change and is the documented starting point when port conflicts, build options, or invocation behavior need investigation.

pnpx @eslint/config-inspector --help

For a project that does not use pnpm directly, `pnpx` still provides the shortest documented entry point, although the repository's own development workflow uses pnpm. Contributors working from a checkout follow a separate path: install dependencies with `pnpm install`, optionally after enabling Corepack as recommended in the README, and run `pnpm cli:dev`. That command first builds the SPA and starts the inspector at `http://localhost:7777`. The README separately notes that `pnpm dev` starts the Vue component development server with HMR, but its payload fetch will fail unless the inspector itself is running.

Static builds versus a live local inspection session

The project offers a genuine alternative to keeping the interactive inspector available: it can export a snapshot as a static single-page application. This is useful when the inspection result must be opened later on another machine, attached to a review, or deployed to a static host. It is also a different sharing model from the live local server because the README describes the output as a snapshot of the config at build time.

pnpx @eslint/config-inspector build

According to the README, this generates an SPA under `dist/__eslint-config-inspector`. The output can be deployed or used for comparison. Since it is a snapshot, it should not be expected to keep receiving configuration edits from the source project. For an active debugging loop, the normal inspector command with automatic updates is the closer fit. For preserving or comparing one state, the static build removes the need to reproduce the same local environment merely to reopen that view.

The repository also provides an online StackBlitz preview. That route is useful for examining the tool before running it against a local project, but it is not a substitute for inspecting repository-specific config unless the project's configuration and relevant files are actually present in that environment. The static output path is specific, which makes it straightforward to include in deployment scripts. Available build options can be inspected through the dedicated help command.

pnpx @eslint/config-inspector build --help

The README does not document authentication for a deployed snapshot, so any static hosting decision must account for the sensitivity of the exported configuration separately. The tool's output concerns lint setup, which can reveal file patterns, ignored paths, plugin choices, and rule policy even when it contains no application source code.

StackBlitz and Nuxt development versus npm package use

Package users and contributors encounter the project through different surfaces. The package is distributed under `@eslint/config-inspector`, exposes a JavaScript CLI entry point, and ships files matching `*.mjs` plus `dist`. That packaging is suited to running the tool from a project with `pnpx`. It also means the complete source tree is not necessarily part of a normal installation; package users should not expect access to contributor-only directories such as `.storybook/`, `tests/`, or `patches/` in the installed package.

Contributors work with pnpm 12.4.2, Nuxt, Vue, devframe, UnoCSS, Vitest, Playwright, and Storybook. The documented production-development checks include `pnpm build`, which builds the inspector tool and CLI, followed by `pnpm start`, which starts the production server at `http://localhost:7777`. The repository also defines unit, Storybook, end-to-end, type-checking, and lint scripts, but those are maintainer workflows rather than requirements for inspecting an existing ESLint config.

This distinction affects upgrade cost. Routine end users mainly need to account for Node.js and ESLint peer compatibility and rerun the CLI after upgrading the package. Contributors or organizations that customize the Vue interface must absorb a larger toolchain. They may need to handle changes across Nuxt configuration, Vue components, UnoCSS, CLI bundling, and the devframe integration. The presence of tests and multiple build targets is useful for project maintenance, but the README does not document a compatibility policy for custom modifications.

Flat-config boundaries, maintenance, and Apache-2.0

The clearest limitation is scope. ESLint Config Inspector is designed for flat configs, particularly a root `eslint.config.js`. It does not advertise support for legacy `.eslintrc` files, remote configuration services, editor-specific rule explanations, or automatic correction of lint failures. It is therefore the wrong tool when the real problem is an ESLint rule implementation, parser behavior, plugin execution, or an error produced while linting source code. In those cases, the configuration may be syntactically visible but still not be the failing component.

A second constraint is the Node.js and ESLint compatibility declared in `package.json`. Unsupported runtime or peer versions are an adoption risk because the package is tightly connected to ESLint configuration loading. The README also does not describe behavior when a config imports unavailable modules, executes environment-dependent code, or throws during loading. Those cases should be reproduced directly with the documented CLI rather than assigned a guessed result.

The repository is not archived. Its last push was on 2026-10-15, and the documented releases include v3.5.0 on 2026-09-16, v3.4.1 on 2026-09-11, and v3.4.0 on 2026-09-02. Those facts indicate recent repository activity and recent releases, but they do not guarantee that every ESLint release will be supported without checking the package's peer range.

The project is licensed under Apache-2.0. The repository links to its `LICENSE` and states the same license in both the README and `package.json`. Apache-2.0 includes standard copyright, license, and notice obligations, but this review does not interpret legal requirements. Teams embedding, redistributing, or statically deploying the generated application should review the actual license text and any notices applicable to their distribution.

Editorial conclusion

Developers debugging ESLint flat config composition should adopt the tool when a visual view, automatic file updates, or a shareable static snapshot will make diagnosis easier. Projects that only need ESLint results, teams that cannot permit a local config inspection server, or users of legacy `.eslintrc` configuration should first verify that their setup matches the tool's flat-config model. The first practical check is that the target project contains `eslint.config.js`, runs on a supported Node.js version, and produces a useful result at `http://localhost:7777/` without exposing its configuration.

Frequently asked questions

Official sources

1. eslint/config-inspector on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases