monokai-pro.nvim: one Lua theme, six colour filters and lazy highlights

Six filters over one Monokai palette

The theme is a Neovim colourscheme written in Lua, and the interesting design decision is that the Monokai Pro look is not a single palette but a family of them. The README lists six filters: Pro, which is the default, plus Classic, Machine, Octagon, Ristretto and Spectrum. The configuration option that switches between them is a single key, and the value is set in the setup call with a comment listing every legal choice, so you can see the whole set at the point where you pick one. That arrangement matters more than it sounds. A theme that hard-codes one palette pushes you into editing highlight tables by hand the moment you want a different contrast level, whereas here the contrast family is a first-class setting and the rest of the theme, from the syntax groups to the plugin highlights, is derived from the active filter.

Installing with lazy.nvim or packer.nvim

The plugin registers as a normal Neovim plugin, and the two documented installation paths both do the same two things: call setup with no arguments and then switch to the colourscheme. With lazy.nvim the spec is written as a table.

{
  "loctvl842/monokai-pro.nvim",
  lazy = false,
  priority = 1000,
  config = function()
    require("monokai-pro").setup()
    vim.cmd.colorscheme("monokai-pro")
  end,
}

The priority of 1000 and lazy = false are what make the theme load before anything else asks for colours, so panels such as a status line or a file explorer do not flash in the default palette on startup. The packer.nvim form is the older equivalent and calls the same two functions.

use {
  "loctvl842/monokai-pro.nvim",
  config = function()
    require("monokai-pro").setup()
    vim.cmd.colorscheme("monokai-pro")
  end
}

Note that setup takes an optional table, so calling it with no arguments at install time and reconfiguring later are both supported.

Configuration is a Lua table, not a colour picker

Everything the theme exposes is an option in the setup table, and the defaults are visible in one place. The headline switches are transparent_background, terminal_colors and devicons, all booleans, and there is a styles table where you can turn italics on for comment, keyword, type, storageclass, structure, parameter, annotation and tag_attribute groups individually. Two options handle behaviour you might not expect to be configurable: inc_search decides whether the search highlight is an underline or a filled background, and background_clear lists the plugins whose backgrounds should be cleared, which by default covers toggleterm, telescope, renamer and notify. There is also a day_night block with enable, day_filter and night_filter, so the same installation can switch between two filters on a schedule instead of forcing one palette for the whole day.

Three Lua hooks for changing colours without patching the theme

The escape hatch that makes this more than a preset is a trio of override functions, all of which take arguments and return a table. override receives the scheme, override_palette receives the filter, and override_scheme receives the scheme, the palette and the colours. The project ships them empty, returning an empty table, so out of the box they change nothing and you are not fighting the theme to get a clean start. The point is that you can hook into any stage of the palette build, whether you want to nudge a single highlight group after the scheme is assembled, alter one filter's palette, or replace the scheme entirely. Since the hook is ordinary Lua, the mutation you write is ordinary Lua too, which is a different proposition from the usual advice of editing a colourscheme file and hoping the next update does not overwrite it.

Plugin highlights load only when the plugin does

The theme handles 33 plugins, and it can defer applying highlights until the plugin is actually present. The mechanism is a lazy field on each plugin spec, with two forms. The event form waits for a Vim event such as VimEnter or FileType, and the module form waits for a module to be required, for instance telescope.

{ name = "treesitter", lazy = false }
{ name = "telescope", lazy = { module = "telescope" } }
{ name = "dashboard", lazy = { event = "VimEnter" } }
{ name = "neo-tree", lazy = { module = "neo-tree", event = "FileType neo-tree" } }

The first line is the eager default, the last one shows both triggers at once, so a plugin can be held until whichever condition arrives first. The project states the goal plainly: reduce initial colourscheme load time by applying highlights only when a plugin is needed. You can check what has actually been applied with a one-liner.

:lua print(vim.inspect(require("monokai-pro.theme.triggers").applied_plugins))

And a plugin can be dropped from the theme's hands entirely.

require("monokai-pro").setup({
  disabled_plugins = { "bufferline", "neo-tree" },
})

Which plugins get which trigger

The plugin table is worth reading because the choice of trigger tells you how the theme expects each plugin to behave. Most are module based, including aerial.nvim, alpha-nvim, blink.cmp, bufferline.nvim, coc.nvim, fidget.nvim, fzf-lua, gitsigns.nvim, indent-blankline.nvim, lazy.nvim, mason.nvim, mini.nvim, neo-tree.nvim, noice.nvim, nvim-cmp, nvim-navic, nvim-notify, nvim-tree.lua, nvim-ufo, packer.nvim, rainbow-delimiters.nvim, renamer.nvim, nvim-scrollbar, snacks.nvim, telescope.nvim, toggleterm.nvim, vim-illuminate, which-key.nvim and wilder.nvim. dashboard-nvim uses an event. nvim-treesitter and the built-in LSP client are listed as eager, since treesitter highlights have to be in place before the first parse and the LSP highlights follow the buffer. lualine.nvim is marked built-in, and it has its own configuration snippet, since the status line needs the theme registered under its own name rather than the colourscheme name.

Status line and plugin-specific options

Some plugins need more than a highlight group, and the theme handles those cases individually. The bufferline section exposes underline_selected, underline_visible, underline_fill and a bold toggle, so you can decide how much of the buffer line is decorated. The indent_blankline section exposes context_highlight, which takes default or pro, plus a context_start_underline switch. The lualine integration is a separate setup call with the theme named in its options.

require("lualine").setup({
  options = { theme = "monokai-pro" },
})

The README also carries a section for Barbecue, though the excerpt of it in the project overview is cut off at the heading, so the details of what it accepts are not visible there. The same is true of a few later sections: the overview ends mid-example. That is worth knowing before you rely on the README alone for a plugin you care about, since the repository also carries a doc/ directory and a CHANGELOG.md that cover more than the overview does.

A refactor in v2.0.0 and what the tags say about it

The project posts a warning above the installation instructions: version v2.0.0 involved a large internal refactor, so short-term regressions are expected, and issues should be reported so the next release can be stabilised. It also asks maintainers of forks carrying fixes to contribute upstream through pull requests. On the release history, three tags landed on the same day, 2026-05-08: v2.1.2, v2.1.3 and v2.1.4, which reads like a burst of fixes after the refactor rather than a steady release cadence. The last push to the repository was on 2026-05-15. The licence is MIT, so the colour definitions and the Lua code can be reused without restriction, and the repository carries a stylua.toml, meaning the Lua source is formatted with StyLua.

Editorial conclusion

monokai-pro.nvim fits a Neovim user who wants a polished dark palette that still adapts to the plugins they actually run, and it fits anyone who likes the Monokai look but wants to bend it with a Lua function rather than by hand-editing highlight tables. It does not fit a user who wants a stable theme with a long history of small fixes, because the project states that version v2.0.0 involved a large internal refactor with short-term regressions expected, and the last push was on 2026-05-15 with the newest tag v2.1.4 from 2026-05-08. Before you commit to it, run the applied_plugins check to see which highlights are actually active on your setup, keep the override functions empty until you know which palette entry you want to change, and read the CHANGELOG.md, since the refactor moved things around under the same command names.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. loctvl842/monokai-pro.nvim on GitHub
4. README
5. Releases