Abracadabra: forty automated refactorings inside VS Code

A refactoring extension aimed squarely at code you did not write

The extension opens with a definition of refactoring, quoted from Martin Fowler's book: a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior. That definition is the whole product brief, and the positioning follows from it. VS Code ships with a few basic refactorings, and Abracadabra is described as supercharging the editor with much, much more of them, shortcuts to trigger the most useful ones quickly, Quick Fixes that suggest refactorings when appropriate, options to customise the experience, and refactorings that work across .js, .jsx, .ts, .tsx, .vue and .svelte files. The target audience is stated plainly in the tagline, refactor legacy code in a snap, and the repository topics list legacy code and refactoring alongside the language names. The primary language of the repository is TypeScript, and the extension itself is published on the Visual Studio marketplace as nicoespeon.abracadabra.

Everything is reachable from the command palette

There are more than forty automated refactorings, and the catalogue of them is linked from the README, with Extract Variable, Extract Type and Flip If/Else given as examples. All of them are available through the VS Code command palette, which means there is a keyboard path to any operation without needing to know a binding. Some refactorings have default keybindings configured, and those can be changed. Everything else is reachable through the Quick Fixes, which you reach by clicking the lightbulb that appears next to the code or with the default Alt and Enter shortcut. The Quick Fix route is the more interesting of the two, because it is how the extension proposes a refactoring in context rather than waiting for you to ask. It is also the route that can be noisy, and the documentation addresses that directly, since Quick Fixes you never use can be disabled in the VS Code settings by looking for the Abracadabra name in the settings.

Highlighting identifiers to separate I/O from pure logic

Beyond the refactorings themselves, the extension ships features that support refactoring work, and the identifier highlighting is the most useful of them. The reasoning is given: when working with legacy code, a very useful refactoring consists in extracting pure logic out of the I/O code that is hard to test, for example HTTP calls, and the highlighting helps you spot all the I/O bits in a chunk of code. You put your cursor over an identifier and press Ctrl + Alt + H, and all references to it are highlighted, and the highlight persists even when you modify the code. Pressing the same key over a highlighted reference removes it, and a third binding removes all highlights from anywhere. The documented use cases go beyond I/O, such as marking all usages of a variable to help regroup them, and identifying variables that are always passed together in function calls.

New references are not highlighted automatically, on purpose

There is a section of the documentation devoted to a limitation, and it is a good example of an editor extension being honest about a trade-off. If you have highlighted a variable and then write more code that refers to the same variable, it will not be highlighted automatically. The explanation is that they could do it, but a naive implementation would constantly parse the AST of the code you are working with, which would probably affect editor performance. The alternative offered is manual: toggle the highlight over the reference once to remove the old highlight, then again to get the new reference, which the documentation calls annoying, and that is why there is a Refresh Highlights command that recomputes the references for you. So the behaviour you get is a deliberate choice between always-accurate highlights and a responsive editor, and the extension takes responsiveness. The three keybindings, toggle, refresh and remove all, are listed in a table with their Mac equivalents.

Four settings decide when the extension stays quiet

The configuration table is the part worth reading before installing, because it determines how often the extension interrupts you. ignoredFolders is a list of folders where it will not propose refactorings, and it defaults to node_modules. ignoredPatterns is a list of glob patterns with the same effect, defaulting to dist and build, and the documentation points at the glob documentation for what you can filter out. maxFileLinesCount stops the extension proposing refactorings on files with more lines of code than the threshold, and the default is 10.000, which in this project's notation is ten thousand, a deliberately high bar that keeps large generated files quiet. getMaxFileSizeKb does the same for file size in kilobytes, with a default of 250. The last setting is a behavioural one: autoConvertToTemplateLiteral, on by default, converts a string into a template literal when you insert the dollar sign and braces. The thresholds are generous by default, so a codebase with very large files will want them lowered, and the glob patterns are where you exclude generated code.

SemVer releases with a change log behind them

The project follows the SemVer convention, and the README spells out what that means in practice, which is rare enough to be worth quoting. The release format is:

<major>.<minor>.<patch>

Breaking changes bump the major version and reset the minor and patch, backward compatible changes bump the minor and reset the patch, and bug fixes bump the patch. The recent releases follow the pattern of naming the version after a song title, with the current one at 9.12.0 named Stand Out, the previous at 9.11.0 named I'll Make a JSDoc Out of You, and 9.10.0 named I'm a Believer. The changelog is linked as the place to see the details of all changes between versions. The last push was on 2026-10-02, and the extension requires VS Code 1.125.0 or newer and Node 22 or newer, which is a recent floor for both.

An extension built with an esbuild pipeline and a code generator

The repository layout shows how the project is put together, and a few entries are worth noting. There is a _templates directory and a hygen setup, and the package scripts include a hygen target and a new command that runs a refactoring generator, which is how a new refactoring gets scaffolded. The build is an esbuild configuration run through node with a --node and a --browser pair, producing a main entry and a browser entry, because a VS Code extension can run in a web host as well as on the desktop. The tests are vitest, and there is a separate contract test path that compiles the sources with tsup-node and then runs a generated contract test runner, and a test:ci script that chains lint, typecheck, unit tests and contract tests. The lint setup has two eslint configs, one for the main source and one for pre-commit, with lint-staged and husky driving the commit hook. There is also a .adr-dir, which is a directory of architecture decision records, and a REFACTORINGS.md file at the root, which is likely where the catalogue of available refactorings is maintained.

Editorial conclusion

Abracadabra suits a team working in a JavaScript or TypeScript codebase they did not write, where the usual refactorings do not reach, and where VS Code's own refactoring support is thin. It does not suit a project that has already invested in a dedicated refactoring tool, and the identifier highlighting will not keep up with code you are writing continuously. Before adopting it, look at the list of available refactorings and the ignoredFolders and ignoredPatterns settings, because the thresholds for when the extension stays quiet are the difference between a tool that helps and one that gets in the way.

Frequently asked questions

Official sources

1. License: MIT
2. nicoespeon/abracadabra on GitHub
3. Project website
4. README
5. Releases