Bun Console icon

Bun Console

An interactive JavaScript and TypeScript console for WebStorm, running on Bun.
Call the functions of the file you are editing, try snippets, and debug them — without leaving the IDE.

Bun Console in WebStorm: calling functions of the open TypeScript file

Contents

Why

You wrote parse() in parser.ts and want to see what it returns for a few inputs. Usually that means a scratch file, a test, or copying code into a browser console. With Bun Console you open parser.ts, open the console and type parse("abc").

If you have used the developer console of a browser, most of it will feel familiar.

Requirements

   
IDE WebStorm 2026.2 or newer (other IntelliJ-based IDEs with the JavaScript and Bun plugins may work, but are not tested)
Runtime Bun 1.4 or newer
Debugger (optional) A Node.js interpreter configured in WebStorm — the bundled Bun debug adapter runs on Node.js

Installation

From JetBrains Marketplace (once published): Settings → Plugins → Marketplace, search for Bun Console, click Install.

From a file: download bun-console-<version>.zip from the releases, then Settings → Plugins → ⚙ → Install Plugin from Disk… and select the zip. No IDE restart is needed.

Make sure Bun is installed:

bun --version

Quick start

  1. Open a JavaScript or TypeScript file of your project, for example:

    // parser.ts
const separators = /[\s,;]+/;

export function tokenize(text: string): string[] {
  return text.split(separators).filter(Boolean);
}
  2. Open the console: View → Tool Windows → Bun Console, or click its > button on the bottom tool-window bar.

  3. Type an expression and press Ctrl+Enter:

    tokenize("a, b;c")          // [ 'a', 'b', 'c' ]
separators.source           // '[\\s,;]+'  — not exported, still available

The tab above the output shows which file is the context (parser.ts · follows editor). Switch to another file in the editor and the console follows it.

Running code

Action Keys
Run the input Ctrl+Enter (or the Run button)
New line Enter
Previous / next command Up / Down on the first / last line, or Alt+Up / Alt+Down
Completion as in the editor (Ctrl+Space)

You can swap Enter and Ctrl+Enter in Settings (Enter runs, Shift+Enter adds a line). The run shortcut can be changed in Settings → Keymap → Run Bun Console Input.

The console input is JavaScript. TypeScript files are loaded and debugged normally, but type annotations typed into the console itself are not supported.

Your files as the console context

The file in the editor

The JS/TS file selected in the editor is the context: its top-level functions, classes, variables and enums are available by name, whether they are exported or not. Names that are already taken in the console (your own variables, globals like process) are left alone; the transcript lists such collisions.

A context file is not executed when you open it. The console reads the file to learn its names; the module’s top-level code runs the first time a command uses one of those names — once, like a normal import. The same applies to the files it imports.

If the whole module namespace is needed, it is available as globalThis['parser.ts'].

Keeping more files: tabs, pin, Add File

Every context file has a tab above the output; clicking a tab opens that file. All tabs share one console: the same input, transcript and variables.

When two context files declare the same name, the file following the editor keeps the short name and the other one gets an alias (shared_2); the transcript tells you which. A default export gets a name from the file (parser_default for parser.ts). Both files stay reachable as globalThis['parser.ts']; when file names repeat, the key includes the folder (left/shared.ts), as shown on the tabs.

Editing context files

Edit a context file and return to the console: it is saved and reloaded before your next command. Your console variables survive. If you changed a file that a context file only imports, the status line asks for Restart Runtime (the ↻ button in the title bar), because the old version is still in use by the modules that imported it.

Non-exported names and CommonJS

Non-exported declarations become available by adding an export { … } list after the module’s last line when Bun loads it; line numbers, stack traces and breakpoints are unaffected. This is also prepared for the files a context file imports, so their names are available when you open them later. If a file was loaded some other way before the console knew about it (for example through a dynamic import()), reading one of its non-exported names says that it needs Restart Runtime.

CommonJS files (module.exports = …) cannot be extended that way: names listed in module.exports work, and reading any other top-level name explains why it is unavailable.

Imports

Static import statements work in the console, in all forms:

import path from 'path'
import { join as combine } from 'node:path'
import * as fs from 'node:fs'
import './setup'
import { tokenize } from './parser'     // relative to the context file
path.basename(combine('a', 'b.txt'))

Imported names stay available until Restart Runtime. Relative paths resolve from the context file, or from the project folder when there is none; packages and built-in modules resolve as Bun resolves them. Importing a name that is already taken asks for an alias. Import attributes (with { type: 'json' }) are not supported yet; dynamic import() works as usual.

Completion in the console offers what the running console actually has: context file names, your variables and imports. It does not offer other project exports, because accepting one would add an import line to the input.

Long-running code and errors

Debugging

Breakpoints in console calls

Turn the debugger on with the bug button in the console’s title bar (or ⋮ → Debugger). The runtime restarts with WebStorm’s Bun debugger attached; the transcript, history and file contexts stay.

Set a breakpoint in a context file and call the function from the console. Execution stops at the breakpoint and the Debug window shows the stack and variables. The status line reads paused at parser.ts:14; input evaluates in this frame, and:

A console call stopped at a breakpoint; the status line shows the pause location

While paused, input evaluates in the stack frame and completion offers its locals

Turn the debugger off with the same button when you don’t need it. If you edit a file that has breakpoints, the console restarts its runtime before the next command so the breakpoints stay attached to the new code.

Your own program paused in WebStorm

This works with the console’s debugger off. Start your own Node.js or Bun program with WebStorm’s regular Debug, stop it at a breakpoint and open Bun Console: the status line shows paused in <session> at file:line, and console input is evaluated in that program’s selected frame. Continue from the ⋮ menu or the Debug window; afterwards input goes back to the console’s own runtime.

Settings

Settings → Tools → Bun Console:

Troubleshooting

“Bun was not found.” Install Bun 1.4+ or choose its executable in the settings. On macOS, an IDE started from the Dock sees your shell’s PATH only if the shell profile exports it.

“Bun Console requires Bun 1.4 or newer.” Run bun upgrade.

The debugger does not attach. The Bun debug adapter needs a Node.js interpreter: set one in Settings → Languages & Frameworks → Node.js. If attaching still fails, the console reports it and continues without the debugger; switch the debugger off and on to retry.

A name “is not available … Restart Runtime”. The file was loaded before the console could expose its non-exported names (see above). Restart Runtime.

The status line asks to Restart Runtime after an edit. A file imported by your context file changed; the modules that use it still hold the old version. Restart to load the new code.

The console is stuck on JavaScript is busy. Synchronous code is still running. Click ↻ Restart Runtime.

Limitations

How it works

The plugin starts a Bun process with a small bootstrap script stored in the IDE’s system folder (nothing is written to your project) and talks to it over a local socket protected by a one-time token. Console input is prepared in the IDE with WebStorm’s JavaScript parser (import statements and repeated declarations are rewritten so that they work in a REPL) and evaluated with Bun’s node:repl in the process’s global scope. File contexts are read with Bun’s transpiler to learn their exports without running them; modules run through Bun’s normal module loader on first use. The debugger is WebStorm’s own Bun debugger attached to the console’s process, and paused-frame evaluation uses the IDE’s debugger API.

Building from source

See docs/development.md for building, testing, running a sandbox IDE and the release checklist.

License

MIT © Petro Borshchahivskyi