CodeArt is a whole Neovim configuration, not a plugin to add to one

A configuration you replace rather than extend

The repository description is six words: Use NeoVim as general purpose IDE. That framing explains the whole delivery model. This is not a plugin you add to a Neovim you already have. It is a complete configuration directory with an init.lua, a lua/ tree of plugin configuration, an installer/ directory of shell and PowerShell scripts, and a lazy-lock.json pinning plugin versions. You clone it into the place Neovim looks for its configuration and you run an installer script. The README is explicit about the consequence, and it is printed twice for the Linux, macOS and Windows sections: please backup any existing configuration files. That is a big commitment for someone with a working setup, and it is the first thing to weigh. The payoff is a configured editor on first launch, with lazy loading, language servers, file tree, fuzzy finder and terminal already wired together. The cost is that the configuration is now the project's, and your own adjustments have to live inside it. The way the project handles that cost is the file lua/user_settings.lua. The README tells you to put customisations there, and later explains why: local edits outside that file, or an uncommitted dirty tree, can block the update command, which runs git pull --ff-only. So the intended workflow is a clean upstream configuration plus one personal overlay file, which is a workable model, but it is also a constraint that a differently structured configuration would not have.

Installing means cloning over your config directory

The install procedure is short, and the sequence matters.

git clone https://github.com/artart222/CodeArt ~/.config/nvim
chmod +x ~/.config/nvim/installer/linux-mac.sh
exec ~/.config/nvim/installer/linux-mac.sh

Note what the first line does. It clones the repository directly into ~/.config/nvim, so any directory already at that path is in the way, which is why the backup instruction comes first. On Windows the same idea with a PowerShell script, run from an administrator session.

git clone https://github.com/artart222/CodeArt $HOME\AppData\Local\nvim
powershell.exe -executionpolicy bypass -file $HOME\AppData\Local\nvim\installer\windows.ps1

The Debian case has an extra step the README calls out separately. If you are on Debian, after the installation finishes you must add the Debian testing repositories, and after that run the apt command to get Neovim.

sudo apt update; sudo apt install neovim

The common mistake is to run the installer before Neovim is present at all, which is why the Debian instruction exists as a separate callout rather than a line in the script. After the installation you open Neovim, run :Lazy sync and reopen the editor. The lazy.nvim plugin manager is what the configuration is built on, and :Lazy sync is what actually fetches the plugins, so the clone alone does not give you a working editor.

Neovim 0.12 and tree-sitter-cli 0.26.1 are hard floors

The requirement line in the README is the most consequential paragraph in the document, and it is written as a warning. CodeArt requires Neovim 0.12+ and tree-sitter-cli 0.26.1 or newer, installed via your OS package manager, for example brew install tree-sitter-cli, and the README adds that this is not npm. After installation you open Neovim and run :Lazy sync, then reopen Neovim. You should upgrade Neovim with your OS package manager if needed, because CodeArt will refuse to load on older versions. Refuse to load is the important phrase. A configuration that degrades on an old Neovim is a worse experience than one that tells you plainly that it will not start, and the project chose the latter. The tree-sitter requirement is a second floor rather than a nicety, because the highlighting is Treesitter based rather than regex based. The CLI is what installs the language parsers, and the README gives you two ways to do that: :TSInstall <language> for a one-off, or setting config.treesitter.ensure_installed in user_settings.lua so the parsers come back after a wipe. Updates go through :TSUpdate. Language servers are installed separately with :LspInstall <language>, which is the Mason convention, and the README also mentions :MasonUpdate in the update flow. The tree-sitter CLI note about not using npm is the kind of detail that costs an hour if you get it wrong, since an npm install of a tree-sitter CLI package is a common first instinct.

Updating, and the dirty tree that stops it

The update path is one command, and the surrounding notes are the useful part. :CodeArtUpdate updates CodeArt config and plugins only, which means git pull --ff-only combined with :Lazy sync, and it does not upgrade Neovim. The README is explicit that Neovim itself is installed or upgraded with your OS package manager, whether that is Homebrew, apt, pacman or winget. The recommended sequence is four steps: run :CodeArtUpdate inside Neovim, restart Neovim, run :MasonUpdate and :TSUpdate if needed, and restart Neovim again. If CodeArt reports that your Neovim is too old after an update, the fix is to upgrade Neovim first and then reopen the editor, since the update path deliberately does not touch the editor binary. Then the warning that explains the whole update design. Very important note: put customizations in lua/user_settings.lua. Local edits outside that file, or an uncommitted dirty tree, can block git pull --ff-only. Stash or commit your changes, or back them up, before updating. That is a real constraint rather than a stylistic note. git pull --ff-only refuses to merge when local modifications would be overwritten, so an edit to any tracked file outside the sanctioned overlay file stops the update. The configuration is opinionated in a way that affects your day to day work, and the README is honest about it rather than pretending the file is optional. There is a CHANGELOG.md at the root, which is where the list of breaking changes lives.

The plugin stack behind the IDE features

The features list names the components, and it is a conventional modern Neovim stack. Lazy loading is the first item, and the README gives a concrete number for it, stating that with lazy loading NeoVim starts up very fast and that it took around 20 milliseconds on a virtual machine with 4GB of RAM and 2 cores. It is a personal measurement on a specific machine rather than a benchmark, and it is the kind of figure worth reading as an indication of the order of magnitude rather than a promise. Language servers give native code completion support with documentation, and highlighting is Treesitter based. The file tree is neo-tree, the built-in terminal is ToggleTerm, the fuzzy finder is telescope, and there is a TODO viewer built on todo-comments.nvim. The migration notes from 1.x are the most informative part of the README for understanding the current stack, because they list the replacements. The mapping is explicit: config.null_ls becomes the config.conform and config.lint tables, config.cmp becomes config.blink, config.nvim_tree becomes config.neo_tree, and the disable_plugins entries for nvim_tree, null_ls and nvim_cmp become neo_tree, conform and lint, and blink_cmp respectively. Read that as a summary of what a 2026 Neovim configuration uses. null-ls, the null-ls based language server tooling, has been replaced by conform for formatting and lint, and nvim-cmp has been replaced by blink_cmp for completion, with neo-tree taking over from nvim-tree. That is a configuration that tracks the current ecosystem rather than a curated set of long standing plugins, which is the right instinct and also the source of the migration burden.

Themes, fonts and the GPL-3 licence

The theme section is a gallery rather than a single look, and it is worth reading as a compatibility signal. Enfocado comes from vim-enfocado. There are several Tokyonight styles, with storm, night and day variants. Nightfly and Moonfly come from the same author, bluz71. Nord is there, and Onedark appears in six styles, dark, darker, cool, deep, warm and warmer. Multiple styles of the same colour scheme is a deliberate choice, and it reflects how people actually use these schemes, since the same palette read at different contrast levels works for a bright office, a dim room and a projector. Then there is the practical warning about fonts. The README says the configurations use many nerd fonts icons, that JetBrains Mono is installed by default, and that if you have problems with fonts and see weird icons you must change your terminal font. That is the honest cost of the aesthetic. The icons are not decorative, they are the file tree glyphs and status indicators, and a terminal without a patched font shows boxes instead. The licence is GPL-3.0, with a LICENSE file at the root of the repository and a badge in the header. Activity is current but the release history is thin. The last push was on 2026-08-07, the repository is not archived, and the releases are v2.1 from 2026-08-07 and v0.1, labelled First release, from 2021-10-30. Most of the work happens in commits rather than in tagged releases, so the configuration you get is whatever the default branch points at.

Editorial conclusion

Adopt CodeArt if you want a fully equipped Neovim IDE without assembling one plugin at a time, and you are happy to keep your personal settings inside lua/user_settings.lua. Do not adopt it if you already have a Neovim configuration you like, since the install clones over ~/.config/nvim, and do not adopt it on Neovim older than 0.12, because the configuration refuses to load. Before you install, back up your existing config, install tree-sitter-cli 0.26.1 or newer through your OS package manager rather than npm, and read the 1.x migration list so you know which plugin changes the update will carry.

Frequently asked questions

Official sources

1. artart222/CodeArt on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases