# unplugin-turbo-console: readable browser logs without the devtools noise

> unplugin-turbo-console is a build plugin that changes what console output looks like in the browser during development, adding output highlighting, prefixes and suffixes, an editor launch shortcut, log forwarding and a console inspector. It ships as an unplugin, so the same package works under Vite, webpack, Rspack, Astro, Farm and Nuxt.

**unplugin/unplugin-turbo-console** — 🚀  Improve the Developer Experience of console

- Repository: https://github.com/unplugin/unplugin-turbo-console
- Website: https://utc.yuy1n.io
- Stars: 712 · Forks: 15
- Language: TypeScript
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/unplugin-unplugin-turbo-console

## The problem: console output that hides the error

The project description is one line, Improve the Developer Experience of console, and the topic list gives the frame: developer-experience, react, svelte, vue, vite, vite-plugin, unplugin. The problem it attacks is mundane and universal. A browser console in a modern app is a wall of unstructured text: application logs mixed with framework warnings, third party chatter and your own messages, all in the same font, with the useful line buried somewhere in the middle. When you are reading fifty such lines to find the one warning that matters, the format itself is costing you time. The README lists the answer as five features rather than an essay, and that flatness is itself informative: output highlighting, prefix and suffix, launch editor, pass logs, and a console inspector. Each of those attacks a different part of the reading problem, from making the line stand out to getting you from the log to the source file.

## An unplugin, so one package covers many bundlers

The packaging decision is the structural fact about this project, and it comes first because it determines what you can adopt it into. The package name is unplugin-turbo-console, its keywords are rollup, transform, unplugin, vite and webpack, and the exports map in package.json has separate entry points for the base package and for ./farm, ./astro, ./vite and ./webpack. Each of those entries declares both an import condition pointing at a .mjs file with .d.mts types, and a require condition pointing at a .cjs file with .d.cts types, which is the pattern for a package that has to work in ESM, CommonJS and TypeScript resolution modes at once. The distribution files are client.d.ts and dist, and the module entry points are dist/index.mjs for ESM and dist/index.cjs for CommonJS, with dist/index.d.mts as the type entry. In short, the plugin is authored once against the unplugin interface and adapters are generated for each bundler.

## The package entry points in detail

Reading the package metadata tells you how a consumer actually gets the plugin, and the shape is standard for a modern bundler plugin. The main field points at the CommonJS build, the module field at the ESM build, and the types field at the .d.mts declaration file, with a typesVersions map that falls back to ./dist/* and then ./* for resolvers that predate the exports field. The license is MIT and the type is module, so the package itself is ESM-first even though it still ships a CommonJS build for tools that need one.

```json
{
  "name": "unplugin-turbo-console",
  "version": "3.0.0",
  "description": "Improve the Developer Experience of console",
  "type": "module",
  "main": "dist/index.cjs",
  "module": "dist/index.mjs",
  "types": "dist/index.d.mts",
}
```

The version matters here because the release history is a major version bump. The recent tags are v3.0.0 on 2026-10-09, with v3.0.0-beta.2 on the same day and v3.0.0-beta.1 on 2026-10-08, so the 3.0 line was stabilised within a couple of days of its last beta. If you are pinning this dependency, expect the 3.0 series to be the one you land on, and check the changelog behaviour of a major bump in a plugin that rewrites output at build time.

## The example projects are the compatibility list

The examples/ directory is the most informative part of the tree, because it enumerates what the plugin has been made to work in. There are separate example projects for astro, farm-vue, nuxt, rspack, solid-start, svelte-kit, vite-vue3 and vue3-cli. That list covers the full spectrum of modern frontend stacks: plain Vite with Vue 3, the Vue CLI path, Nuxt, SvelteKit, Astro, SolidStart, Rspack as the webpack-compatible alternative, and Farm as the newer Rust-based bundler. The presence of a farm-vue example lines up with the ./farm export in package.json, and the presence of a nuxt example lines up with the Nuxt server logs feature listed in the credits, since Nuxt has its own server logging that the plugin is credited with drawing on. The vue3-cli example is the interesting one, because the Vue CLI is a webpack-based tool that predates the Vite plugin API, and supporting it means the plugin had to be authored against a shared interface rather than against one bundler.

## Where the project sits in the lineage of similar tools

The README credits five prior projects, and reading that list is the fastest way to understand the design. babel-plugin-enhance-log, turbo-console-log, vite-plugin-console-line, vite-plugin-terminal and Nuxt's server logs feature are each credited, which tells you the feature set was assembled from work that had already been done in narrower scopes. The Babel plugin and the console-line plugin both work at the transform layer, which is the same layer this project works at. vite-plugin-terminal is a terminal display plugin, close in spirit to the pass logs feature, where log output is forwarded out of the browser to a terminal instead of being trapped in the devtools panel. Nuxt's server logs feature is a server side feature rather than a browser one, and it is the precedent for the idea of making log output readable by a human rather than a machine. The credit list is also a caution: each of those projects solved a slice of the problem in a specific bundler, and this one consolidates them behind a single unplugin interface.

## What the repository layout says about the work

Beyond the examples, the tree shows a full package development setup. There is src/ for the plugin source, client/ for the client-side runtime, client.d.ts as the published type surface, test/ for the test suite, docs/ for the documentation that the README links to at utc.yuy1n.io, and vite.config.ts for building the package itself. The tooling choice is pnpm, with pnpm-lock.yaml and pnpm-workspace.yaml at the root, and a .node-version file pinning the Node version for contributors. Two entries are worth a second look. skills-lock.json, together with an .agents/ directory and an AGENTS.md file, indicates that the repository is set up for agent-driven contribution, with the skills lock recording the assistant tooling versions. The .vite-hooks/ directory suggests the build pipeline itself is extended through Vite hooks, which is a reasonable way to keep the plugin's own build consistent with the bundler it targets.

## The limits of a development-only console treatment

The clearest limitation is inherent in the category. This is a developer experience plugin that changes how console output is presented in the browser, and the features it lists are all about presentation and navigation: highlighting, prefix and suffix, launching the editor, passing logs along, inspecting the console. None of that is a logging backend. If you need logs shipped somewhere, queried, retained and correlated, you need a different tool entirely, and this one will not help. The second limit is the flatness of the documentation in the README itself. The feature list gives five names and no configuration keys, no options and no explanation of what pass logs does under the hood, so the README cannot tell you whether a feature needs a browser extension, a server endpoint or nothing at all. The documentation site is where the detail lives, and the README does not reproduce it. A third point follows from the release shape: v3.0.0 landed on 2026-10-09, so if you are upgrading from a 2.x installation you should read the release notes for breaking changes rather than assume the transform behaves the same way. The repository is not archived and the last push was on 2026-10-15, so the code is moving, and moving fast.

## Conclusion

Adopt unplugin-turbo-console if you spend your day reading browser console output during development and want readable, highlighted, prefix-tagged logs that also open the right file in your editor, and if you want one package to work across Vite, webpack, Rspack, Astro, Farm and Nuxt. Do not adopt it if you need structured machine readable logs in production, since this is a development experience tool that changes how console output is presented, and do not expect it to replace a real log aggregation backend. Before installing, check which of the five features you actually want, since the README lists them as a flat set with the configuration details on the documentation site at utc.yuy1n.io, and confirm your bundler is covered by the exports map in package.json.

## FAQ

### What does unplugin-turbo-console do?

The README lists five features: output highlighting, prefix and suffix, launch editor, pass logs and a console inspector. The project description is to improve the developer experience of console, so it changes how browser console output is presented during development.

### Which bundlers does unplugin-turbo-console support?

It is built as an unplugin, and package.json exposes separate entry points for ./vite, ./webpack, ./astro and ./farm alongside the base export. The examples directory contains projects for astro, farm-vue, nuxt, rspack, solid-start, svelte-kit, vite-vue3 and vue3-cli.

### How is unplugin-turbo-console installed and used?

The package is published on npm as unplugin-turbo-console, and the README links a StackBlitz project for trying it without a local setup. Configuration details are on the documentation site at utc.yuy1n.io, which the README links as the documentation entry.

### What is the current version of unplugin-turbo-console?

package.json lists the version as 3.0.0, matching the v3.0.0 release tag dated 2026-10-09. The two preceding tags are v3.0.0-beta.2 on 2026-10-09 and v3.0.0-beta.1 on 2026-10-08.

## Sources

- [License: MIT](https://github.com/unplugin/unplugin-turbo-console/blob/main/LICENSE)
- [Project website](https://utc.yuy1n.io)
- [README](https://github.com/unplugin/unplugin-turbo-console/blob/main/README.md)
- [Releases](https://github.com/unplugin/unplugin-turbo-console/releases)
- [unplugin/unplugin-turbo-console on GitHub](https://github.com/unplugin/unplugin-turbo-console)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/unplugin-unplugin-turbo-console