Dracula for Visual Studio Code: one palette, two variants, a lot of waiting

Two variants, one palette, and a soft option that changes the background

The manifest is the most informative file in the repository, because a colour theme is mostly a data file plus the build that produces it.

The package is named theme-dracula with the display name Dracula Theme Official, published by dracula-theme under the MIT licence, and the description calls it the official Dracula Theme, a dark theme for many editors, shells and more. The repository field points at the visual-studio-code repository, and the categories are Themes with the keywords dracula, dark, theme and color-theme.

The contributes block is where the two variants are defined:

        "themes": [
            {
                "label": "Dracula Theme",
                "uiTheme": "vs-dark",
                "path": "./theme/dracula.json"
            },
            {
                "label": "Dracula Theme Soft",
                "uiTheme": "vs-dark",
                "path": "./theme/dracula-soft.json"
            }
        ]

So the extension contributes two colour themes, both flagged as vs-dark, pointing at two generated JSON files. The soft variant is the interesting one, because it keeps the same hue assignments while lowering the contrast of the background surfaces, which is the difference between a theme you can stare at for a long session and one that is vivid.

The gallery banner is set to the colour #3c4557 with the theme marked dark, which is the purple-grey that the palette uses for its surfaces, and the icon is an icon.png in the repository root.

This is a theme package, not an extension with code of its own. The JavaScript in the repository is build tooling, not runtime behaviour, and the whole thing that ships to the editor is the generated theme JSON.

The build is a Node script and a lint step, and that is the whole pipeline

The scripts in the manifest are four lines, and they describe the entire lifecycle of the project.

        "build": "node ./scripts/build.js",
        "lint": "node ./scripts/lint.js",
        "package": "vsce package -o ./bin/dracula.vsix",
        "vsce-publish": "vsce publish"

The build script generates the theme files, the lint script checks them, the package script runs vsce to produce a .vsix into a bin directory, and the publish script pushes it to the marketplace. There is a vscode:prepublish hook that runs the build before packaging, so a published package always contains freshly generated themes rather than whatever happened to be in the working tree.

The repository layout is consistent with that. There is a src directory holding the source of the theme, a scripts directory with the build and lint scripts, a .vscode directory and a .vscodeignore, an .editorconfig, a .prettierrc.toml, a jsconfig.json, and a package-lock.json. There is also an INSTALL.md, a known_issues.md, a CHANGELOG.md, a screenshot.png, an icon.png and a dracula-pro.png.

Two of those files are worth more attention than they look. known_issues.md is a repository that exists to record what does not work with this theme, which is a better signal of care than a list of features would be. INSTALL.md is the local installation route, separate from the README, which simply says all instructions can be found at draculatheme.com/visual-studio-code.

The engines field pins the editor version at ^1.13.0, which is a very old floor and tells you the theme has always been careful about not depending on newer manifest features, which matters because a theme that breaks on a new VS Code release is a theme that gets uninstalled.

The devDependencies include js-yaml, which is the giveaway that the source of truth for the theme is YAML that the build script converts into the JSON that VS Code consumes.

The release tags and the version in the manifest tell different stories

There is a discrepancy in this repository that anyone evaluating it should notice, because it is the kind of thing that only shows up when you actually look.

The recent releases listed on the project record are v2.24.3 from 2023-07-15, v2.24.2 from 2022-03-20 and v2.24.1 from 2021-12-13. The version in the package manifest is 2.25.1. So the manifest says a version later than the last tagged release, and the last tag is more than three years old relative to the last push to the repository on 2026-10-19.

The last push date is recent, so the repository is not abandoned, and the repository is not archived. But the tagged release history has been static since 2023, which means the version a marketplace user installs and the version in the source tree are not obviously the same thing, and there is no tag to point at when you want to know what changed.

The maintenance arrangement is also worth stating plainly. The README says the theme is maintained by Derek S. and a bunch of contributors, and the manifest lists three maintainers, Derek Sifford, Lucas de França and Zeno Rocha, along with a named list of contributors. There is a CHANGELOG.md in the repository, so the change record exists even if the tags do not.

For a user, the practical difference is that you should expect to install from the marketplace or from the project site rather than to build a specific commit, and if you do build from source, the CHANGELOG.md is where you look for what a given version contains.

It is worth being fair about what this repository is. It is a colour palette expressed as an editor theme, and the difficult intellectual work happened once when the palette was designed. Everything since then is maintenance, which is why the diff history is small and the changelog matters more than the code.

How a theme is distributed and where the instructions actually live

The install path is short, and the README does not describe it, which is unusual but reasonable for a project whose install is a marketplace entry.

The README points to draculatheme.com/visual-studio-code for all instructions, and the repository carries an INSTALL.md for the local route. The distribution channel is the Visual Studio Code marketplace, since the packaging script uses vsce, the marketplace command line tool, and the package declares the category Themes so it is listed among colour themes rather than among extensions.

The theme is described as a dark theme for Visual Studio Code, and the README leads with a screenshot rather than a feature list, which is the correct choice for a visual product. The homepage is draculatheme.com/visual-studio-code and the project has a broader identity, the manifest description says the Dracula Theme is a dark theme for many editors, shells and more, which means the same palette appears across a family of projects and that a user moving between them gets a consistent result.

The commercial side sits alongside. The README links Dracula PRO, and the repository carries a dracula-pro.png asset for that banner, while the MIT licence covers the theme in this repository.

The community channels are named with a recommendation for each: Twitter is described as best for getting updates about themes and new stuff, GitHub Discussions as best for asking questions and discussing issues, and Discord as best for hanging out with the community. The contributing guide is at .github/CONTRIBUTING.md, and the README asks contributors to read it first.

So the practical install is the marketplace, the practical source of truth for problems is GitHub Discussions, and the practical source of truth for what changed is the CHANGELOG.md in the repository.

Where a single-palette theme is the wrong choice

Three situations rule it out, and the first one is about what a theme can and cannot do.

The first is if you need a theme designed around language semantics. Dracula is one palette applied to a syntax highlighter, which means every language, every token type and every UI surface is drawn from the same set of colours. A theme designed per language can give a different accent to types, classes and keywords in a way that makes structure readable at a glance. A single palette cannot, because there is only one palette. If your work depends on reading structure from colour rather than from indentation and shape, this is not the theme that solves it.

The second is if light environments are part of your day. Both variants declare uiTheme as vs-dark, and there is no light counterpart in the manifest. The soft variant lowers contrast, which is a mitigation for long sessions, not a light theme.

The third is the release situation, for anyone who needs a specific version. The last tagged release is from 2023 while the manifest carries 2.25.1, and there is no tag to pin to for the current state of the tree. For a theme that a person installs once and forgets, that is a minor point. For a team standardising an editor configuration across a fleet, or for anyone who needs to reproduce an environment from a version, the absence of a current tag is a genuine problem, and the CHANGELOG.md is the fallback.

The MIT licence is as simple as it gets, and the dependencies are limited to a YAML parser and the packaging tool, so the licensing and the dependency footprint are both non-issues here. The interesting constraint is the design one: this is a palette, and a palette is a constraint by nature.

Editorial conclusion

Dracula for Visual Studio Code fits a developer who already uses the palette in other tools and wants VS Code to match, and the two variant approach means you can take the full contrast version or the soft one without leaving the theme family. It is the wrong choice if you are looking for a theme with a wide set of semantic roles for every language, since the scope here is one palette applied to the editor rather than a designed colour system per language. Before installing, read known_issues.md in the repository, because that file is where the limitations are recorded, and check the INSTALL.md in the repository rather than the README, which sends you to the project site for the actual instructions.

Frequently asked questions

Official sources

1. dracula/visual-studio-code on GitHub
2. License: MIT
3. Project website
4. README
5. Releases