nvim-scissors: editing VS Code snippets without touching JSON

The problem is the JSON, not the snippets

nvim-scissors describes itself as automagical editing and creation of snippets, and the rationale section says why that is a thing worth a plugin.

The VS Code snippet format is, in the documentation's words, the closest thing to a standard regarding snippets. It is used by friendly-snippets and supported by most snippet engine plugins for nvim. However, VS Code snippets are stored as JSON, which are a pain to modify manually. The plugin's job is to alleviate that pain by writing the JSON for you.

That framing matters, because it tells you the plugin is not competing with snippet engines. LuaSnip, mini.snippets, blink.cmp and the rest of the supported list are the things that expand a snippet once you have typed its prefix. nvim-scissors is the authoring tool that sits upstream of them, and it is a completely separate concern from the expansion engine.

The supported list is long and specific: LuaSnip, mini.snippets, blink.cmp, basics-language-server, nvim-snippets, vim-vsnip and yasp.nvim. The plugin is MIT licensed, written in Lua, and the last push to the repository was on 2026-08-03, with no GitHub releases published.

One thing the plugin will not do is read other snippet formats. The documentation is explicit that only VS Code style snippets are supported, and it points at snippet-converter.nvim as the way to convert from other formats.

The popup window, the hot reload and the JSON conversion

The feature list describes what the plugin actually does day to day, and most of it is about the editing loop rather than the snippet format.

You can add new snippets, edit snippets, or delete snippets on the fly. While you edit there is syntax highlighting, and it covers the parts of a snippet that are not plain text: tabstops and placeholders such as $0, ${2:foobar}, or $CLIPBOARD. There is automagical conversion from buffer text to JSON string. The editing interface is described as intuitive, dynamically adapting the number of prefixes.

Then there is the part that changes how the plugin feels in use. There is automatic hot-reloading of any changes, so you do not have to restart nvim for changes to take effect. The plugin also prettifies snippet files for clean diffs in version control, and offers optional JSON formatting and sorting of the snippet file, which the documentation says is useful when version-controlling your snippet collection.

Snippets and files are selected through telescope, snacks, or vim.ui.select, and the plugin can bootstrap the snippet folder or new snippet files if they are needed.

So the loop is: open the popup, type or paste the body, watch the JSON get written, and see the result in your buffer without restarting. The prettifying and the optional sorting exist for a specific reason, which is that a JSON file edited by hand produces diffs full of whitespace, and a snippet collection is exactly the kind of thing people keep in Git.

Two settings that have to agree

The installation section is where most of the friction is, and it comes down to one requirement stated twice.

The plugin needs a snippetDir. The snippet engine needs to look in the same place. These are separate settings in separate plugins, and nothing in the code makes them agree for you.

The plugin is installed with vim.pack or lazy.nvim, and in both cases you pass the snippet directory:

-- vim.pack
vim.pack.add({ "https://github.com/chrisgrieser/nvim-scissors" })

require("scissors").setup({
    snippetDir = "path/to/your/snippetFolder",
})

-- lazy.nvim
{
	"chrisgrieser/nvim-scissors",
	opts = {
		snippetDir = "path/to/your/snippetFolder",
	}
},

Then the snippet engine is pointed at the same folder, and the plugin's documentation gives a separate snippet for each supported engine. LuaSnip loads from a path list:

require("luasnip.loaders.from_vscode").lazy_load {
	paths = { "path/to/your/snippetFolder" },
}

vim-vsnip takes a global variable, and yasp.nvim takes a path to a package.json file, which is a good hint about how each engine expects to find snippets:

vim.g.vsnip_snippet_dir = "path/to/your/snippetFolder"
-- OR
vim.g.vsnip_snippet_dirs = { "path/to/your/snippetFolder" }

The mini.snippets case is the one worth reading twice, because the default location does not match where the plugin wants to write. The preferred snippet location for mini.snippets is any snippets/ directory in the runtimepath, and for manually maintained snippets the best location is the user config directory, which needs its own setup call:

require("scissors").setup({
	snippetDir = vim.fn.stdpath("config") .. "/snippets",
})

The tip given is that vim.fn.stdpath("config") returns the path to your nvim config. The note that follows matters too: nvim-scissors works only with VS Code style snippet files, not Lua files or JSON arrays, and it requires a package.json for the VS Code format.

What the plugin needs from the rest of your setup

The requirements list is short enough to quote in full, and it is worth reading as a checklist rather than a formality.

Neovim 0.12 or newer. Snippets saved in the VS Code style snippet format. A snippet engine that can load VS Code style snippets, from the list of seven above.

Then the recommended part: one of the pickers. telescope, snacks.nvim or fzf-lua. The reason given is worth repeating, because it is a difference in kind rather than degree. Without one of them, the plugin falls back to vim.ui.select for snippet selection, and that fallback lacks search and snippet previews. With hundreds of snippets in a collection, the difference between a searchable fuzzy picker and a flat list of entries is the difference between usable and not.

Optional are Treesitter parsers for the languages you want syntax highlighting for, which is the language of the code you are writing, not the language of the snippet.

A picker is therefore close to required in practice, even though the documentation frames it as recommended, and that is a detail worth understanding before you decide the plugin is not for you because you do not use telescope.

The blink.cmp and basics-language-server setups are also worth a glance, because they show that the plugin integrates at two different levels. blink.cmp is configured through its snippet provider with a search_paths option, and basics-language-server is configured through lspconfig with a snippet sources list, which means the snippet folder becomes a language server source rather than a plugin option.

Format details that decide whether a snippet works

The cookbook section of the documentation covers the parts of the VS Code format that people get wrong, and the plugin's own output has to satisfy the same rules as anything written by hand.

Tabstops and variables are the core syntax, and the feature list names the three forms the plugin highlights while you edit: $0 for the final cursor position, ${2:foobar} for a numbered placeholder with a default value, and $CLIPBOARD for a variable that pulls in the system clipboard. Any of these can be typed into the popup, and the highlighter makes them visible as you go, which is the practical difference between a snippet editor and a JSON editor.

The file structure is equally constrained. Snippets are stored as JSON, and a VS Code style snippet file is a JSON object whose keys are snippet names and whose values are objects with a prefix, a body which is an array of lines, and a description. The plugin writes exactly that shape, and the documentation is clear that the plugin needs a package.json for the VS Code format, which is the file that declares the snippet language.

The friendly-snippets section points at the community collection as the reference example of the format, which is useful if you are deciding what your own collection should look like, and the tip about snippet-converter.nvim covers the case where your snippets currently live in a different format and you want to move them across.

The last piece of the format story is version control, and it is the reason the prettify and sort options exist. A snippet collection that is edited by a machine and a collection that is edited by hand produce very different diffs, and only the first stays readable over time.

Where nvim-scissors is the wrong choice

The first limitation is the format restriction, and it is absolute. The plugin works only with VS Code style snippets, not Lua files or JSON arrays. A team whose snippets are Lua definitions, which is a common choice in nvim configurations, cannot use it at all without converting first.

The second limitation is the nvim version floor. Neovim 0.12 or newer is required, which is a recent enough release that anyone on an older nvim is out of luck. This is a reasonable constraint for a new plugin and it is still a constraint, and it interacts with the snippet engine list, since those engines have their own version requirements and their own update cadence.

The third limitation is that the plugin is an authoring tool and nothing more. It does not expand snippets, it does not provide a fuzzy finder of its own, and it does not manage a snippet collection across projects. The expansion is the engine's job, the picking is telescope's or snacks' job, and the syncing of a collection between machines is a separate problem the plugin does not address.

The real alternative, and the difference in approach is about where the JSON lives, is to keep snippets as Lua files and accept that they are not VS Code format. A nvim-scissors user gets the VS Code standard, the ability to share a collection with users of other editors, and the conversion machinery, and pays for it in JSON and a required package.json. A Lua-based snippet collection is more pleasant to write, more flexible in what it can express, and it stays inside the editor, and it cannot be read by an editor that expects the standard. The pragmatic version of the choice is that if you already use a VS Code snippet collection, nvim-scissors removes the part of that setup you would otherwise hate, and if you do not, the plugin is solving a problem you do not have yet.

Editorial conclusion

Adopt nvim-scissors if you keep your snippets in the VS Code format and want to edit them in a popup instead of a JSON file, since the conversion it does by hand is the reason the plugin exists. Do not adopt it if your snippets are in another format, since the plugin works only with VS Code style snippets, and do not adopt it on nvim below 0.12. Before you install it, point your snippet engine at the same snippetDir you give the plugin, because the two settings are independent and a mismatch is the failure the documentation keeps warning about.

Frequently asked questions

Official sources

1. chrisgrieser/nvim-scissors on GitHub
2. Issues
3. License: MIT
4. README