The description says 0.5, the README says 0.9

The floor and the variant count differ from the README

Two numbers in the repository disagree with the README, and both are the kind you find out about the hard way. The one-line description says the theme is for neovim >= 0.5.0 and that it comes with 5 color variant styles. The README body says the theme is for neovim >= 0.9, and the requirements section states Neovim 0.9.0 or newer, with the reason given: modern Tree-sitter captures, LSP semantic tokens and full feature support. The style count differs in the same way. The feature list says 8 theme styles, broken down as One Dark plus 5 variants and One Light plus 1 variant, which is seven named styles rather than eight, and the options list in the configuration section names exactly seven: dark, darker, cool, deep, warm, warmer and light. So the arithmetic in the feature line does not produce the number it claims. If you are filtering themes by topic or reading the description before cloning, treat the README as the accurate source and the description as stale.

Four plugin managers, then one style call

The install section is organized by Neovim version rather than by plugin manager, which is the more useful organization.

require('onedark').setup {
    style = 'darker'
}
require('onedark').load()

That two-call pattern is what every snippet below reduces to, whichever manager installed it. For Neovim 0.9 and newer you install from master, and the same snippet is given for four plugin managers. With vim.pack it is vim.pack.add taking the repository URL, then a setup call and a load call. With Lazy it is a table with the plugin name, a priority of 1000 and a config function, where the comment says the priority makes sure it loads before all other start plugins. Vim-plug is one line, and Packer is one line using use. For Neovim 0.5 to 0.8 the instruction is to pin to tag v0.1.0, and each of the same managers gets its pinning syntax: a version field for Lazy, a tag argument for vim-plug, and a table with tag for Packer. Below 0.5 the README points at a different project entirely, joshdick/onedark.vim, so there is a defined answer for every era rather than a warning.

Enabling the theme means setup then load

Enabling the theme takes two forms in the configuration section. The Lua form is require('onedark').load(), and the Vim form is colorscheme onedark, which is what a user without any Lua configuration needs. Choosing a different default style is the same pair with a setup call in between: require('onedark').setup with style set to darker, then load. The Vim equivalent declares a global dictionary, g:onedark_config, with a style key, and then calls colorscheme onedark. Two details in the snippets carry over from the install section: the setup call is what sets the style, and load is what applies it, so a configuration that sets the style and never calls load will keep the previous colors. The Lua path also means the plugin is a module with a setup function rather than a plain colorscheme file, which is why priority matters in a plugin manager: the theme has to be defined before other plugins read it at startup.

The style names are the customization surface

Seven names are offered in the options list and they are not equally different in kind. dark, darker, cool, deep, warm and warmer are six dark variants that shift the same palette along two axes, cool versus warm and increasing contrast, and light is a single light variant. What a variant actually changes is described in the customization section rather than in the feature list: you can customize the colors, the highlights and the code style, with the customization section as the reference. The other feature worth naming is runtime switching. toggle_style_key lets you change the theme style without exiting Neovim, which is the feature that separates this from a colorscheme file with a single fixed palette, and it is what makes trying six dark variants a two-second exercise rather than a configuration edit. The screenshots in the themes section show the dark variants side by side, which is the fastest way to see how much they diverge.

The older line is maintained by tag, not abandoned

The requirements section does something many themes do not, which is to name the version that still works for the older generation. Neovim 0.5 to 0.8 users are directed to tag v0.1.0, with the pinning syntax spelled out for each plugin manager rather than left to the reader. That is a small piece of maintenance with a large practical effect: someone on an older Neovim is not left guessing whether the current master will break their editor, and someone upgrading understands that the jump from 0.8 to 0.9 is also a jump between two incompatible lines of this theme. The published versions tell their own story, with v1.0.1, v1.0.2 and v1.0.3 all cut within minutes of each other on the same day, the last two described as a comment color fix plus IndentMini support and a fix to JSX, TSX and HTML highlighting. Three point releases in the same minute is a burst of fixes rather than a development cadence, and the last push to master was on 2026-04-13.

Tree-sitter is the reason for the version floor

The dependency that shapes this theme is Tree-sitter, and the requirement line explains what it buys. Neovim 0.9.0 or newer is needed for modern Tree-sitter captures, LSP semantic tokens and full feature support, and the syntax highlighting in the theme is Tree-sitter based. That is a meaningful design choice for a colorscheme, because Tree-sitter highlighting produces more tokens than a regex-based syntax file, and a palette that only covers regex tokens leaves those new capture names uncolored. It also explains why the theme supports plugins with hand-picked colors rather than only syntax groups: plugin authors define their own highlight groups, and a theme that picks colors for those is doing work a syntax file cannot. The same dependency is why the fix history includes a JSX, TSX and HTML highlighting correction, since those languages go through Tree-sitter grammars whose capture names differ from what a legacy syntax file would define.

Where this theme is the wrong choice

Four cases. The first is Neovim 0.5 to 0.8, where the only option is the v0.1.0 tag, which by definition lacks the current variant set and the current fixes. The second is Vim, or Neovim below 0.5, where the README sends you to a different project entirely rather than offering a build of this one. The third is a team that wants one theme for the whole toolchain. This covers Neovim only, so an editor setup spanning Vim, an IDE or a terminal multiplexer needs other work, and the Atom One Dark family it derives from exists elsewhere for that reason. The fourth is someone who wants to design a theme from scratch rather than adjust one. The customization surface is colors, highlights and code style within an existing palette, which is the right scope for a variant picker and the wrong scope for a designer building a new scheme. What you get here is a well-trodden palette with a runtime switch between closely related dark treatments, and nothing about it constrains what you can do with your own.

Editorial conclusion

onedark.nvim suits a Neovim 0.9 or newer user who wants One Dark with hand-picked plugin colors and can toggle between variants without restarting the editor. It does not suit anyone on 0.5 to 0.8 who wants the current features, since those require the pinned v0.1.0 tag, nor a Vim user. Before adopting, install from the branch matching your Neovim, call setup with a style before calling load, and check the option list yourself since the variant count in the feature list does not add up to the names it offers.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. navarasu/onedark.nvim on GitHub
4. README
5. Releases