About the project

vite-debug-plugin is an open-source project by MARS TECH, published on npm under the @mars-tech scope as @mars-tech/vite-debug-plugin. The source code is on GitLab: mars-tech/vite-debug-plugin.

Release notes for 1.0.0

1.0.0 is the first stable release. $debug now logs like console.log, shows where each call really comes from, plugs into Vue DevTools, and masks secrets in more places. Production builds are stripped more reliably.

• Several values at once, printf-style, in the browser and in the terminal.
• Live objects in the browser console, expandable as with console.log. They are shown as masked text instead when browser-side redaction patterns are set.
• Console groups, tables and object dumps that use the browser's native console features.
• The real file:line of every call, in your original source, in the same src/Cart.vue:12:3 format in the browser, the terminal and server-rendered pages.
• Vue DevTools integration: in Vue and Nuxt apps, every call also appears in a MARS-TECH inspector and timeline. Install @vue/devtools-api to enable it.
• An opt-in log file for tools and AI assistants: one JSON line per call, already masked, kept out of git. For security reasons, do not use it when your code logs secrets, even masked ones.
• New options: a default namespace filter, and the error stack attached by default to every call that logs an error.
• Easier to use in tests and tooling: a configurable test logger, public types from the main entry, and ESLint 10 support.

On the security side, your string secrets now stay on the dev server, redaction covers much more of each call, logged text can no longer take control of your terminal, a web page can no longer crash, freeze or flood the dev server through $debug, and development code no longer reaches production builds by the routes it used to take. Redaction remains a safety net, not a vault: never log production secrets.

Upgrading from 0.6.1? Most projects need only a few option renames. The old option names keep working, with a warning, until 2.0.0. Migrating from 0.6 lists what to change.

Changelog

Every release is described in the changelog on GitLab, with every fix and every breaking change.

Security

The security policy on GitLab is the reference. In short:

Reporting a vulnerability

Do not open a public issue. Report privately: open a confidential issue on GitLab and tick "This issue is confidential" before submitting, or send an email to the address given in the security policy, with a subject that starts with [SECURITY]. Include the plugin, Vite and Node.js versions, whether it reproduces in dev, in a production build or both, a minimal reproduction, what is exposed and to whom, and any redact or redactDefaults configuration involved.

The project is maintained by a small team, so these are targets, not a contract: an acknowledgement within 5 business days, an initial assessment within 10, and a fix released as fast as the severity warrants. Reporters are credited in the changelog unless they ask not to be. Give the maintainers a reasonable window to publish a fix before disclosing publicly.

Supported versions

Security fixes land on the latest published minor of the current major line. 1.0.x is the supported, current release line. 0.6.x receives security fixes only, for a transition period: upgrade to 1.0. Versions before 0.6 are not supported.

What counts as a vulnerability

The plugin is a development tool whose purpose is to print diagnostics. The question is whether it reveals information to someone who should not see it, or somewhere it was not supposed to go. In scope, for example:

• a redact or redactDefaults rule that masks one output surface but not another it covers;
• a string redact entry, or anything else only the Vite process should hold, reaching anything the dev server hands a page;
• a $debug call surviving a production build, or a library.debugBuild variant placing anything unintended in a consuming app's production bundle;
• a page that bypasses server-side redaction, writes control sequences to your terminal, or grows the dev server's memory or disk without bound;
• anything the dev server sends back to a page;
• code execution through the plugin's transform or generated code.

Out of scope: diagnostics in your own console or terminal during development (that is the product), values you configured no redactor for, attacks that need untrusted code already running in your dev server, vulnerabilities in dependencies (report them upstream), and anything only reachable by editing vite.config.ts. The limits of redaction are documented in What redaction does and does not cover: a known, documented limitation is more useful to the maintainers as a feature request than as a vulnerability report.

The dev server sends nothing back

The plugin holds one rule on the dev server: it never sends anything derived from a log record to the dev origin. There is no endpoint, no HMR message, no acknowledgement or error frame, no DevTools channel and no served file for it. Logs only travel from the browser to the server.

Any script on the dev page can send log lines of its own, and the dev server masks them with your string redact entries, which the page never has. If that script could read back what the server made of its lines, it could tell which of its guesses were masked and recover an entry one character at a time. That is why the NDJSON log file is kept from the page. This protection is a safety net, not a vault: a route nobody has found yet may still hand the log to a page. Do not turn output.file on when your code logs secrets, even redacted ones; a log you keep anyway belongs outside the project, outside server.fs.allow (in a monorepo, the workspace root), where Vite refuses every file. Keep production keys out of a dev setup altogether. A report of a new route to a log under the project is in scope.

Contributing

Contributions, bug reports and feature requests are welcome. Read the contributing guide for the development setup, branching model, commit conventions (Conventional Commits), DCO sign-off and the merge-request checklist.

For security vulnerabilities, do not open a public issue: see Security.

Issues

File bugs, request features or browse open work on the GitLab issue board of vite-debug-plugin.

Versioning

The project follows Semantic Versioning 2.0.0, with two project-specific rules:

• Breaking changes ship only in a major version. A renamed plugin option keeps working for the whole major version, with a one-time warning that names its replacement, and is dropped in the next one. An option removed outright warns once instead of failing silently. Each change is called out in the changelog, and the migration guide gives its before/after snippet.
• The peerDependencies.vite range and the engines.node floor are part of the public API: narrowing the first or raising the second is a major change.

License

MIT, © MARS TECH. See the license file.