nv-ide: a Neovim configuration for full stack web work, now built on LazyVim

The configuration now sits on LazyVim, and the old version is on a branch

nv-ide is described as a Neovim custom configuration, oriented for full stack developers working in Ruby on Rails, Ruby, PHP, HTML, CSS, SCSS and JavaScript. The primary language is Lua and the licence is Apache-2.0.

But the first line of the README is the one that matters, and it is a migration notice. The project has moved on LazyVim as core, and the old original nv-ide can be found under the branch nv_ide_original.

That branch layout is the single most important fact for anyone picking this up. The master branch is no longer a standalone configuration; it is a set of additions on top of LazyVim, which is itself a widely used Neovim distribution. If you were to clone master and symlink it as your nvim directory expecting a self-contained setup, you would be missing the base it assumes.

The author is also candid about the motivation. The repository description says the configuration is used mainly to keep track of changes made to the author's own Neovim setup, with the hope that it will be useful to others, and the README says the project is constantly changing.

The homepage is at locatelli.dev/nv-ide, and there is an INFO.md at the repository root alongside init.lua, lazyvim.json and lazy-lock.json.

So the audience is a web developer setting up Neovim who wants a starting point that already has the right language servers and file tooling, rather than assembling one from scratch.

The plugin list is where the actual configuration decisions live

The suggestions section lists the plugins, and reading it tells you what a Rails and JavaScript development setup actually needs in 2026.

The LazyVim extras are the first group, and the naming tells you they are optional add-ons: lazyvim.plugins.extras.ai.sidekick for AI assistance, lazyvim.plugins.extras.coding.mini-surround, lazyvim.plugins.extras.coding.yanky for yanking with a preview, and lazyvim.plugins.extras.ui.edgy for the window borders.

The core tools are more telling. esmuellert/codediff.nvim is described as providing VSCode-style diff rendering with two-tier highlighting at line and character level, in side-by-side and inline layouts, using VSCode's algorithm implemented in C. That is a performance-conscious choice, and it is a plugin that does not exist in a stock Vim setup.

neovim/nvim-lspconfig is the quickstart configuration for the language server, which is the foundation for the Ruby, PHP and JavaScript support the project is aimed at. TheNoeTrevino/haunt.nvim provides ghost text bookmarks. nacro90/numb.nvim peeks lines just when you intend. chrisgrieser/nvim-rip-substitute gives search and replace with an incremental preview and modern regex syntax, and chrisgrieser/nvim-spider adds w, e and b style subword motions.

For files, stevearc/oil.nvim is a file explorer where you edit the filesystem like a buffer, and SirZenith/oil-vcs-status adds version control status symbols to that oil.nvim buffer. nvim-tree/nvim-web-devicons provides Nerd Font glyphs for the plugins that want them.

And then there is the set of small, sharp plugins that make the difference in daily use: lambdalisue/suda.vim as an alternative to sudo.vim with limited Windows support, tpope/vim-abolish to work with several variants of a word at once, tpope/vim-endwise to add endwise blocks intelligently, jeffkreeftmeijer/vim-numbertoggle with no description provided, tpope/vim-rails as Ruby on Rails power tools, and christoomey/vim-tmux-navigator for moving between tmux panes and vim splits.

Reading that list is the fastest way to decide whether this setup fits, and it is where a prospective user should spend their time.

Installation is a shallow clone and a symlink

The installation section is four lines, and it is worth reading them together because the symlink is the part people get wrong.

git clone --depth 1 https://github.com/crivotz/nv-ide.git ~/.nv-ide
cd ~/.config
ln -s ~/.nv-ide nvim
nvim

So the repository is cloned shallowly into a dot directory in your home, you change into the .config directory, and you create a symlink named nvim pointing at the clone. The consequence is that your entire Neovim configuration directory is the repository, which is what you want if you intend to commit your own changes to it, and what you do not want if you expected to merge it into an existing configuration.

The dependencies are Neovim itself and LazyVim. The README suggests JetBrains Mono as the font, which is the usual choice for a terminal with Nerd Font glyphs, and links a dot_files repository for the rest of the shell setup.

Launching nvim is the last step because LazyVim bootstraps itself on first run, resolving and installing the plugins declared in lazyvim.json and the versions pinned in lazy-lock.json. Those two files are the core of the configuration, and they are the reason the project is worth reading even if you do not adopt it: lazyvim.json is the declaration of what is enabled and lazy-lock.json is the exact commit of every plugin, so a clone of this repository gives you a reproducible plugin set rather than a floating one.

The project also has a .neoconf.json file, which is the configuration for neoconf, the plugin manager's own helper for managing and inspecting the plugin list.

A Lua and Ruby generator sits alongside the Neovim configuration

There is a detail in the repository listing that is easy to overlook and says something about how the project is maintained.

Alongside init.lua, lazyvim.json, lazy-lock.json and the lua/ directory, there is readme_gen.rb, a _config.yml, a stylua.toml and an .editorconfig.

readme_gen.rb is a Ruby script, and the project description says it is oriented for full stack developers including Ruby on Rails. A README generator written in Ruby is exactly the tool a Rails developer would reach for, and it is in the repository because the plugin list in the README is generated rather than written by hand. That is why the README can list twenty plugins with descriptions and stay current as the lockfile changes.

The _config.yml is a Jekyll front matter file, which is the convention for a GitHub Pages site, and the screenshots/ directory plus the SVG header image point at a published project page.

stylua.toml is the formatter configuration for StyLua, the Lua formatter, and the .editorconfig sits alongside it so that the Lua and the generated Markdown agree on whitespace. The .gitignore and .gitattributes complete the tree.

The lua/ directory is the actual configuration code, following the standard LazyVim layout where configuration is split into files by concern and merged with the plugin spec format.

So the repository is a small piece of tooling as well as a configuration: a generator that keeps the documentation in step with the lockfile, and a formatting setup that keeps the Lua tidy. That is the kind of housekeeping that tells you whether a dotfiles repository is a serious artefact or a weekend experiment.

Where nv-ide is the wrong tool

The first wrong-tool case is a user who wants a self-contained Neovim setup. On the current master branch the configuration assumes LazyVim is the base. If you want one repository that works on its own, the branch to look at is nv_ide_original, and that is the version the author has moved away from.

The second case is a developer outside the web stack this targets. The plugin list is Rails and JavaScript shaped: vim-rails, lspconfig for the web languages, oil.nvim and codediff.nvim for working across a project. There is nothing here for a Python, Rust or Go shop beyond what LazyVim provides by default, so the value of this repository over plain LazyVim is close to zero in that case.

The third case is someone who expects stability. The README says the project is constantly changing, the author describes the repository as a way to track changes to his own configuration, and the repository has no GitHub releases. There is no version to pin and no changelog to read, so the reproducibility you get comes from lazy-lock.json rather than from a tagged release, and the configuration may change shape between clones.

There is also a licensing angle worth noting. The project itself is Apache-2.0 with a LICENSE file at the root, but the plugins it pulls in carry their own licences, and the list includes code under the MIT licence and others. Adopting a configuration means adopting that dependency tree, and the licence of the configuration file itself does not cover what it installs.

What you get in exchange for the dependency on a base distribution and a plugin tree this size is a working setup immediately, with the language servers, the file explorer and the diff view already configured. If that is what you were going to spend an evening assembling anyway, this repository saves the evening.

Editorial conclusion

nv-ide suits a web developer who wants a Neovim setup that already has the plugins for Ruby on Rails and JavaScript work wired together, since the plugin list is a usable reference even if you adopt only parts of it. It does not suit someone who wants a self-contained configuration, because the current master branch depends on LazyVim as its core, and it does not suit a user who will not read the plugin descriptions. Before adopting, look at lazyvim.json and lazy-lock.json to see exactly what is enabled and pinned, and decide whether to start from this repository or from LazyVim and cherry-pick the extras.

Frequently asked questions

Official sources

1. crivotz/nv-ide on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README