svelte-intellij gives JetBrains IDEs Svelte support, with snapshot style tests

The feature list, and what each entry buys you

The plugin description is short and lists what it does for Svelte in a JetBrains IDE: syntax highlighting, code formatting, typing assistance, Emmet-style abbreviations of Svelte blocks, completions of components, props and some directives, auto import of components, navigation from components to their definition, and debugger integration.

The list is worth reading closely because each item is a different kind of IDE capability. Highlighting and formatting are table stakes, and a plugin that only did those would not be interesting. The interesting ones are in the middle. Completions of components, props and some directives mean the IDE knows what a Svelte component is and what its props are, and the qualifier some directives is an honest admission that the directive coverage is partial. Auto import of components removes the tedious part of wiring a new component into a file. Navigation from a component to its definition is what you actually spend time on in a large Svelte codebase.

Debugger integration is the item that stands apart, because it is the one feature that depends on the rest of your toolchain rather than on the plugin alone.

Two installation routes, one of them the built-in plugin system

The plugin installs the way most JetBrains plugins do, through the IDE's own plugin system. The README describes the path in interface terms: Settings or Preferences, then Plugins, then Marketplace, then search for Svelte, then Install Plugin.

The second route is manual. You download the latest release from the repository's releases page and install it from disk, again through Settings or Preferences, then Plugins, then the gear icon, then Install plugin from disk.

That second route matters more than it usually does, because the manual install is how you run a locally built version of the plugin. The contributing section says to clone the repository and run the runIde Gradle task, which opens a sandbox IDE with the plugin loaded, and the ready-to-share zip archive ends up in the build distributions directory after the buildPlugin task. So the loop for a contributor is: build, install the zip from disk, and test in a real IDE.

The plugin is published on the JetBrains marketplace under plugin number 12375, and the README badges show its marketplace version and download counts.

Compatible IDEs, and the version question the marketplace answers

The plugin works in JavaScript-enabled JetBrains IDEs, which is a broader statement than it looks. WebStorm is the obvious home, but the phrasing covers the other IDEs that ship with JavaScript support, and the repository contains module files for more than one of them, including separate IntelliJ module files for the main WebStorm plugin and for the tests.

The compatibility detail is delegated to the marketplace rather than to the repository. The README says that information about version compatibility and older releases is available in the version history on the plugin's marketplace page. That is the normal arrangement for a JetBrains plugin, since the compatibility range is a property of the published artifact against IDE builds, and the marketplace tracks it per release.

For a user, the practical advice is to check the version history before installing rather than after, because a plugin that does not declare compatibility with your IDE build either refuses to load or behaves unpredictably. The plugin version badge in the README is the same number the marketplace page shows.

Building the plugin, and why a JavaScript primary language is odd here

The contributing section starts with a small observation about the stack: IntelliJ Platform runs on the JVM, yet Kotlin feels a lot like TypeScript, and the IntelliJ Platform SDK documentation is a good starting point.

The repository layout shows a build that is not a single one. There is a build.gradle.kts and a settings.gradle.kts with a Gradle wrapper, and there is also a BUILD.bazel file alongside .iml module files, which is the IntelliJ module system used by the JetBrains plugin template. The source lives under src, with separate directories for the JavaScript debugger integration, for css, and for media.

The primary language of the repository is recorded as JavaScript, and that is worth sitting with for a moment. The IntelliJ Platform itself is JVM based, and the plugin APIs are Java and Kotlin, but the code in this repository is largely JavaScript, with the separate javascript-debugger directory suggesting the debugging support is implemented in the language of the thing being debugged. That is a defensible choice for a plugin whose whole job is to understand a JavaScript framework, and it also means a contributor coming from the Svelte side rather than the IntelliJ side has a shorter distance to travel.

Tests are committed snapshots, and updating one means deleting it

The test approach is the part of the contributing guide most likely to surprise, and it is described as similar to Jest snapshots in the IntelliJ Platform.

The workflow has three steps. You create a .svelte file in the test resources directory, then add a function whose name is composed of the word test and the file name to the appropriate class. When you run the test for the first time, a file with the expected results is created, and you commit it. When you update the test, you delete the snapshot file and rerun the test, which regenerates it.

So the expected output is a committed artefact rather than an assertion written by hand, and the review of a change is a review of a diff in that artefact. That has the usual trade-off. It is cheap to write and it captures output that is awkward to express as assertions, but it also means a snapshot can be regenerated to match broken behaviour, and the discipline depends on the reviewer reading the diff rather than the file appearing.

The tests run with the Gradle test task, and the README recommends using the run action in IntelliJ IDEA instead, which is the usual way to run a single IntelliJ Platform test with its fixture.

Where the plugin is the wrong tool

The first and simplest case is the editor. This is a JetBrains plugin, so it does nothing for you in Visual Studio Code, in Neovim, in Sublime, or in an editor you run in the browser. If your team is not on a JavaScript-enabled JetBrains IDE, this is not the answer, and the Svelte language server is the thing that works across editors, though it is a different kind of tool with different features.

The second case is a team that wants the IDE to stay out of the way. A plugin that formats, completes, auto imports and offers quick fixes is a plugin that changes your files, and a project that has decided its formatting is decided by a tool in the terminal will find the formatter fighting it.

The third is the version gap, and it deserves attention. The published releases are v0.22.1 from 2022-05-25, v0.22.0 from 2022-03-30 and v0.21.2 from 2021-12-23, while the last push to the repository was on 2026-10-20. The repository is not archived, so work continues, but the marketplace artifact is old. A plugin that has not been republished in years may not load in a recent IDE build, and the marketplace version history is where you find out. That gap is the main thing to verify before building a workflow around this plugin.

The last limitation is the one the plugin itself hints at in the feature list, the qualifier that some directives are supported for completion. If your codebase leans on the less common parts of the Svelte template syntax, expect gaps.

Licence, ownership and the state of the project

The plugin is released under the MIT Licence, with the licence file at the root of the repository. There is also an OWNERSHIP file, which is the file that records who owns the plugin, and it is what lets the project be transferred or maintained by a group rather than one person, which matters for a plugin that ships inside other people's IDEs.

The other files in the root tell the rest of the story. There is a CHANGELOG.md, a .editorconfig for formatting, the .github directory for the workflows including the build badge the README shows, and a gradle.properties plus the gradle directory for the wrapper. The media directory holds the header image used in the README, and the css directory suggests some styling assets for the plugin's own UI.

On the rhythm, the release history is the interesting part. The tags stop in May 2022, at version 0.22.1, and the plugin page is where the compatibility story is tracked. The repository, by contrast, has commits up to October 2026 and is not archived, which reads as a project where maintenance happens in the repository while the published artifact is refreshed less often.

The README's contribution invitation is short, with a link to the IntelliJ Platform SDK documentation for newcomers and a note that the IntelliJ IDEA Community Edition is free and sufficient for building the plugin, with Ultimate also usable if you have a licence.

Editorial conclusion

svelte-intellij fits a team on WebStorm or another JavaScript enabled JetBrains IDE that wants Svelte files to be understood rather than treated as opaque text, and who prefer a plugin they can build and patch locally over a web-only tool. It is the wrong choice if your editor is not a JetBrains one, and you should check the marketplace version history before assuming the plugin you install matches the IDE you run, since the published releases stopped in 2022 while the repository kept moving. Before you rely on it, check three things: that the version on the marketplace supports your IDE build, that the debugger integration works with your bundler setup, since that is the feature most dependent on the surrounding toolchain, and that the auto import behaviour matches your project layout, because component discovery depends on where the plugin finds your Svelte files. The plugin is MIT licensed, the last push was on 2026-10-20, and the latest published release is v0.22.1 from 2022-05-25.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. tomblachut/svelte-intellij on GitHub