Console Ninja puts console.log output beside the line that logged it

Console output is displayed in the editor, anchored to the code that produced it

Console Ninja is a VS Code extension that displays console.log output and runtime errors directly in your editor from your running browser or node application. The framing the README uses is a comparison with two things a developer already has open: the browser dev tools console tab and terminal output from a node app. The difference the extension promises is not new logging, it is where the values appear. Instead of a separate panel, values are connected to your code and displayed in the editor.

The practical consequence is that a log line sits next to the statement that produced it. When a function returns something unexpected, the output and the source share a screen, so there is no window juggling between a browser tab and a file. For a project that logs heavily, that removes a repeated context switch rather than adding capability.

Runtime errors are part of the same flow, which matters more than the logging itself. An uncaught exception in the page appears in the editor at the point where it happened, instead of only in the console where the stack trace points back into framework internals. The README describes the Community edition as including displaying console.log output and runtime errors directly in your editor, and says that unless a feature is documented as PRO it will always be available in the Community edition for free.

Two feature sets ship inside one extension, and the split is the pricing model

The extension comes with a Community feature set and a PRO feature set, and you switch between them in the extension settings. The Community set is described as free to use and always free to use. The PRO set is paid and includes everything in Community plus advanced features.

The licence mechanics are simple enough to describe in a sentence. You can request a trial period for the PRO feature set using the Console Ninja: Manage License command in VS Code, and the paid tier is sold as a subscription on the account.wallabyjs.com shop page for Console Ninja. Since the extension itself is one artefact, the tier is a runtime entitlement rather than a different download, which means a team can start on Community, hit a wall, and then try PRO on the same setup without reinstalling.

What you get on Community is not a demo. The documented Community list covers console.log, console.trace, console.time, network logging, a hover tooltip, a log viewer, universal node applications and runtime log capture options. That is a working debugging setup on its own. PRO adds capabilities rather than gating the basics.

The PRO list is where advanced debugging work is actually located

The PRO feature set covers a wide range of instrumentation features. The documented list includes Log Map, Logpoints, Network logging Pro, Function logpoints, File Code Coverage, Class logpoints, Predictive logging, Hover tooltip Pro, Log Viewer Pro, Filtering Pro, Quick Search Pro, Tracepoints, Timepoints, GitHub Copilot integration, MCP Server and Interactive Value Graphs.

Read as a group, these fall into three families. The logpoint family (Logpoints, Function logpoints, Class logpoints, Tracepoints, Timepoints) lets you attach logging to code locations instead of editing source by hand. The analysis family (File Code Coverage, Filtering Pro, Quick Search Pro, Log Map) works over the recorded log stream, which is where the Log viewer and the hover tooltip become more than a text dump. The integration family (GitHub Copilot integration, MCP Server) exposes the captured values to other tools, and Interactive Value Graphs is the feature aimed at watching a value change over time.

The README states the intended audience for PRO as larger numbers of logs, medium and large company projects, and realtime value watching and diffing. The Community-to-PRO boundary therefore sits where manual inspection stops scaling: once a log stream grows past what a person can scan, the filtering, search and mapping features are what make it usable, not the raw capture.

Framework support comes with documented gaps in server side errors

The supported technology list is long, and the honest part is the footnotes. Vite is covered, including applications generated by the Vite CLI for React, Vue, Preact, Lit, Svelte, Vanilla, TypeScript or JavaScript, plus frameworks built on Vite such as Nuxt and SvelteKit. Webpack is covered for Create React App, Angular CLI, Angular Nx, Gatsby.js and any application configured to use the webpack node module.

Then the exceptions begin. Next.js has first class support for browser and server side logs, both Node and Edge, but Next.js middleware is currently not supported, and Turbopack support is a PRO feature. Nest.js works when you use Nest.js 10 or newer with SWC as the compiler. Remix supports client and server side logs but no errors. Astro supports client and server side logs but no server side errors. Jest is listed as a test runner with no errors.

Read together, the pattern is that error capture is the fragile part. The extension reports errors reliably where the runtime stays in a page the extension can instrument, and drops error reporting where the code runs in a framework layer the extension cannot attach to. A team relying on Remix or Astro error surfacing will get logs and will have to catch exceptions another way. Turbopack, by contrast, is not a gap but a paid tier.

Node scripts take the universal node applications path, not the browser path

Beyond the bundled toolchains, Console Ninja documents support for node app.js style workflows including Express, Hapi, Fastify and other similar frameworks, and it says custom node applications are supported too. That path is described under Universal node applications, and it also carries the runtime log capture options settings that let you decide what is recorded.

The same list covers a set of servers and runners that are easy to overlook: Serverless Offline, Cypress.io as an end to end test runner, and the http-server, live-server and serve static HTTP servers. Two VS Code extensions, Live Server and Live Preview, are supported but are off by default and have to be turned on in the Console Ninja extension settings. That default is worth knowing, because a developer who expects the extension to attach to a Live Server preview will see nothing until the setting is flipped.

React Native with Expo is listed with first class support for logs in iOS and Android emulators, but emulator logs are a PRO feature, while the Web simulator is not. The recurring pattern across the whole list is that basic log capture is broadly available and anything beyond it drifts into the paid set.

This repository holds questions and issues, not the extension source

The repository description is plain about its purpose: it is a repository for Console Ninja questions and issues. The top level entries are .github/, LICENSE.md and README.md. There is no source tree, no build configuration and no package manifest, and the project has no GitHub releases.

That has direct consequences for an engineer doing an adoption review. You cannot read the extension code to confirm what it injects into your page, you cannot build it yourself, and you cannot fork it. Issues and feature requests are the contribution model, and the README asks that you raise an issue if you want support for another technology, since the team says adding support for new tools is fast and easy.

The licence is another review point. The repository is marked as using a licence that GitHub cannot classify, which means a custom licence file rather than a standard open source licence, and the file is named LICENSE.md. The README also splits the product into a free Community edition and a paid PRO edition sold by subscription, so the commercial relationship runs through account.wallabyjs.com rather than through the repository.

Compare that shape with the other tools the README names in its differences section, Quokka.js, Wallaby.js and the Error Lens extension. All three are named as alternatives, and the README gives each its own subsection, so you can read the comparison there. The important structural difference is not in the features but in the delivery: Console Ninja reaches you as a VS Code extension with a commercial tier, not as a library you vendor into a repository.

Install comes from the VS Code marketplace, and the last push was on 2026-06-04

The README section for getting started describes Console Ninja as designed to fit into typical dev workflows, and the supported technologies list is effectively the compatibility matrix to check before you install. Since the repository contains no build files and no releases, the extension is distributed through the VS Code marketplace under the Console Ninja listing, with the project homepage at console-ninja.com.

Two settings are mentioned by name in the README and are worth checking straight after installation. The Live Server and Live Preview extensions are off by default and must be enabled in the Console Ninja extension VS Code settings if you rely on them. The feature set switch between Community and PRO lives in the same settings area, and the Console Ninja: Manage License command is where a trial for the paid set is requested.

On maintenance, the repository is not archived and the last push was on 2026-06-04. There are no GitHub releases, so version history lives in the marketplace and in the change notes the extension itself surfaces, which means upgrade behaviour is something you observe in your own editor rather than something you can read from release tags. Because the extension injects itself into a running application, an upgrade is a change to the code path your app runs, so pinning the extension version across a team is the sensible move if you need reproducible debugging behaviour.

Editorial conclusion

Console Ninja fits front end and node developers who are tired of switching to a dev tools tab, and the Community edition alone covers console.log, console.trace, console.time, network logging and the log viewer. It does not fit teams that need to read the extension source, audit it or self host it, because this repository carries only questions and issues under a custom licence. Before adopting it, install the Community edition from the VS Code marketplace, run the node app.js style workflow listed under Universal node applications, and confirm that your framework is not one of the documented gaps such as Next.js middleware, Astro server side errors or Jest error capture.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. wallabyjs/console-ninja on GitHub