IntelliJ IDEA Keybindings: a JetBrains keymap port for VS Code

A mapping table, not a reimplementation of IntelliJ

The premise is simple enough to state in one line: this is a port of IntelliJ IDEA key bindings for VS Code. The description in the marketplace listing says exactly that, and the extension category is Keymaps, which is the correct category for what it does.

The word port is doing real work in that sentence. A port maps a JetBrains action to a VS Code command with a particular key combination, and it inherits the limits of mapping. Some IntelliJ actions have no VS Code equivalent, some have an equivalent that behaves differently, and some have an equivalent that only exists in a particular editor language. This project handles that honestly: the README tabulates every action with a supported marker, and where the port does not apply it writes N/A.

The scope is wider than IntelliJ proper. The README says the extension includes keymaps for popular JetBrains products such as IntelliJ Ultimate, WebStorm, PyCharm and PHP Storm, so a user arriving from a Python or web IDE gets the same muscle memory as one arriving from the Java flagship.

For a developer who moves between the two editors daily, the value is not that VS Code becomes IntelliJ. It is that the handful of shortcuts used most often, completion, reformat, generate, refactor, and file navigation, still land in the same place.

The tables separate what works from what silently does not

The bulk of the README is a set of tables grouped by area: Editing, Search/Replace, Usage Search, Compile and Run, and Debugging. Each row gives the Linux and Windows binding, the macOS binding, the feature name, and a supported marker.

Reading them is a good way to judge the port. The Editing table shows the shortcuts that carry over cleanly: ctrl+alt+l for reformat code, alt+enter for intention actions and quick fixes, ctrl+o for override methods, ctrl+i for implement methods, ctrl+alt+o for optimize imports, and the whole family of fold and expand bindings, from ctrl+= to expand a code block through ctrl+alt+= to expand recursively. The generate code action maps to alt+insert on Linux and Windows and cmd+n on macOS.

The N/A rows are the informative half. Smart code completion, which filters methods and variables by expected type, is N/A because VS Code has no equivalent of that filter. Surround with, which wraps a selection in an if, else, try, catch, for or synchronized block, is N/A too. Structural search and replace are marked as Ultimate Edition only features and are not ported. Paste from recent buffers, auto-indent lines, indent and unindent selected lines, and toggle case for a word at the caret are all N/A.

A user migrating from IntelliJ will feel the N/A rows more than the supported ones, because the missing actions are the ones that make IntelliJ feel fast. The tables let you know in advance which habits will not carry over.

fast-xml-parser is the bridge to JetBrains keymap files

The manifest explains the mechanism in one dependency. The extension has exactly two runtime dependencies, fast-xml-parser and path-browserify, and the first is the important one. IntelliJ stores its keymaps as XML, and fast-xml-parser is the library used to read that XML, while path-browserify provides a path resolution shim for the browser based extension host.

So the extension does not hand write every binding. It reads IntelliJ keymap definitions and maps them onto VS Code commands. That is why the same extension can offer keymaps for several JetBrains products, since the underlying data is per product, and it is why a JetBrains release that adds a new action or changes a default shortcut can be reflected without rewriting the extension logic.

The build side tells the same story from the other direction. The project is TypeScript, compiled by webpack with ts-loader, and the dev dependencies include TypeScript itself, the VS Code type definitions, ESLint with a Prettier config, and a copy plugin. The manifest declares the extension as not an AMD module and lists no extension dependencies, so it does not require another extension to be installed first.

There is also a small tool of its own. A script named gene-keybind-markdown.js lives under src/tool, and the manifest exposes it as a usage script, which is how the tables in the README are produced from the same data the extension loads.

The extension declares a minimum VS Code version and nothing else

The manifest states the requirement plainly. The engines field names vscode with a version constraint of ^1.138.0, and the current extension version is 1.7.8 with publisher k--kato. If your VS Code build predates that engine floor, the extension will refuse to activate, which is the one hard failure mode here and the first thing to check.

Two other declarations are worth reading. The capabilities block sets untrustedWorkspaces to supported, so the extension is willing to run in a workspace you have not trusted, which is a meaningful statement for an extension that reads configuration from disk. The categories array contains a single entry, Keymaps, and the keywords are IntelliJ, Keybinding and keymap.

The build is a normal extension build. The scripts section defines a prepublish hook that runs the package script, a compile script that runs webpack, a watch script, a package script that produces a production bundle with a hidden source map, a lint script that runs ESLint across the TypeScript and TSX files, and the usage script for generating the key binding markdown.

	"compile": "webpack",
	"watch": "webpack --watch",
	"package": "webpack --mode production --devtool hidden-source-map",
	"lint": "eslint . --ext .ts,.tsx",
	"usage": "node ./src/tool/gene-keybind-markdown.js"

The lint and package commands are the two you would run in a checkout, and the source tree matches the layout you would expect: a src directory, a test directory, a resource directory, images, a webpack configuration, a tsconfig, an ESLint config in flat config form, and Prettier configuration files.

A keymap extension, installed from the marketplace

The distribution path is the Visual Studio Marketplace, under the extension identifier k--kato.intellij-idea-keybindings, and the README links to that listing directly through a marketplace badge. The badge set in the README also shows the install count and the marketplace version, both of which are the kind of figure that changes between releases and should be read as a snapshot rather than a promise.

There is no bundled download and no self hosted deployment to arrange, which is the right shape for a keymap. A keymap is a settings overlay, and the useful life of one ends when the target editor changes its command identifiers or when the upstream JetBrains keymap changes, so continuous distribution matters more than a stable binary.

The repository itself is the place to look if you want to change something rather than use it. The top level holds the source under src, tests under test, resources under resource, and a package-lock.json alongside the manifest, alongside editor and formatting configuration such as a.jsbeautifyrc, a.prettierrc.yml and a.prettierignore.

The documentation for this project is the README itself, and it is documentation in the narrow sense: a set of tables rather than a narrative. There is no guide to a first run, no troubleshooting section and no note about what to do when a binding conflicts with a shortcut another extension already claimed, so the tables are the whole contract.

The version record shows a slow but steady release line

The maintenance picture is unremarkable in the best way. Version 1.7.8 was published on 2026-09-21, 1.7.7 on 2026-02-22 and 1.7.6 on 2025-11-01, and the last push to the repository was on 2026-10-04. The repository is not archived. Those two facts together mean the project is being worked on, and that the gap between published versions can stretch to several months, so a reader deciding whether to depend on it should not expect a monthly release.

For a keymap extension, a slow release line is not alarming in the way it would be for a security tool. The extension does not sit on a network path, it does not hold credentials, and its behaviour is defined by tables that change slowly. What matters is that the tables stay aligned with the JetBrains releases people actually use, and the version numbers in the manifest and the marketplace listing are the thing to watch rather than commit dates.

The licence is MIT, stated in the manifest, in the README badge and in the LICENSE.md file at the repository root. That is a permissive grant with no copyleft obligation on downstream use, and the same terms apply to any keymap file you generate from this project and then modify for your own team.

One upgrade detail to keep in mind. The extension declares a minimum VS Code version, so when the extension or your editor updates, the pairing can break in one direction, with an extension too new for your editor, and the fix is a VS Code upgrade rather than anything on the extension side.

Where the port is the wrong tool

The honest answer is that this extension is the wrong tool for anyone who wants IntelliJ's editing model. It does not bring smart type filtered completion, it does not bring surround with, it does not bring structural search and replace, and it does not bring paste from recent buffers. Those are marked N/A in the tables rather than approximated, which is a design decision you should respect and also a boundary you should notice before you migrate a workflow.

The narrower mistake is installing it and expecting the IDE-level actions to work. A keymap changes what a key does. It does not add a feature that the editor does not have, and the missing rows are precisely the IntelliJ features that have no VS Code counterpart. Someone whose day depends on reformatting a selection into a try/catch block will find the habit broken.

There is a second, quieter cost. The port follows JetBrains defaults, which are not identical across JetBrains products, and the extension ships keymaps for several of them. If you use two JetBrains IDEs with different keymap settings, one VS Code keymap will match one of them and not the other, and the tables do not resolve that ambiguity for you.

Finally, the extension is versioned against the editor, and the engine constraint of ^1.138.0 means a managed or older VS Code install may not qualify. A team that pins its editor version across a fleet should check that constraint before standardising on the extension, because a keymap that silently fails to activate looks like a broken keybinding rather than an unsupported extension.

Editorial conclusion

Adopt this extension if you spend your day in JetBrains editors and have to work in VS Code without relearning every shortcut, and you can live with the actions the tables mark N/A, which include smart code completion, structural search and paste from recent buffers. Do not adopt it to make VS Code behave exactly like IntelliJ, because the port is a mapping table, not a reimplementation of IntelliJ features such as surround with or intention actions on every platform. Verify first that your VS Code version satisfies the declared engine requirement of ^1.138.0, read the keymap tables in the README for your platform, and check that the shortcuts you actually rely on are the ones marked supported before you uninstall your old editor.

Frequently asked questions

Official sources

1. kasecato/vscode-intellij-idea-keybindings on GitHub
2. License: MIT
3. Project website
4. README
5. Releases