CLI tool
romus204/tree-sitter-manager.nvim avatar
romus204/tree-sitter-manager.nvim

tree-sitter-manager.nvim: installing Tree-sitter parsers without nvim-treesitter

A lightweight Tree-sitter parser manager for Neovim.

881 stars46 forksTree-sitter QueryMIT

At a glance

What is it?
tree-sitter-manager.nvim is a Neovim plugin that installs and removes Tree-sitter parsers, copies the highlighting queries, and exposes a TUI for managing them, written after nvim-treesitter was archived. It suits Neovim 0.12 users who still need a way to fetch a parser for a language.
Who is it for?
tree-sitter-manager.nvim is a good fit for a Neovim 0.12 user who needs a working parser for a language, who has the tree-sitter CLI and a C compiler on the machine, and who would rather not depend on an archived plugin.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 2 days ago.
What is it written in?
Mainly Tree-sitter Query, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.

Editorial analysis

Neovim got Tree-sitter but not a parser installer

The gap the plugin fills is stated precisely, and it is a small, specific gap rather than a general dissatisfaction with Neovim. Although Neovim 0.12 integrated Tree-sitter into the core, it still lacks a built-in parser installer, and with nvim-treesitter now archived, this plugin provides a lightweight, actively maintained alternative that makes installing parsers and adding new languages straightforward. The three things it does are installing and removing parsers, automatically copying the queries for syntax highlighting, and managing parsers through a clean text interface. What it does not do is anything with your configuration beyond that. It is not a highlighting engine, it is not a language server, and it does not manage the runtime queries that already ship with Neovim. The scope is deliberately narrow, and the readme's own framing of it as lightweight and minimal suggests the author wanted a replacement for one specific plugin rather than a new Neovim workflow.

The requirements are a CLI, a compiler and git

The mandatory requirements are Neovim 0.12 or later, the tree-sitter CLI, git for cloning the parser repositories, and a C compiler, either gcc or clang, for building the parsers. The optional requirement is a Nerd Font, for the interface to display its icons properly, which the readme marks as needed for the check, cross and package icons. With lazy.nvim the plugin is added like this, and note that the dependency list is empty because the tree-sitter CLI has to be on the system already:

lua
{
  "romus204/tree-sitter-manager.nvim",
  dependencies = {}, -- tree-sitter CLI must be installed system-wide
  config = function()
    require("tree-sitter-manager").setup()
  end,
}

The dependency on a C compiler is the one worth thinking about, because it is what makes this a different kind of plugin from most Neovim plugins, which are pure Lua. A Tree-sitter parser is a C library, and building one needs a toolchain, so the plugin is not something you can drop into a purely managed environment without a compiler present. The tree-sitter CLI is the other half, because the plugin uses it to generate the parser binding rather than shipping prebuilt objects, which is what allows it to support arbitrary languages and forks. The lazy.nvim installation snippet notes this explicitly, with the dependencies list empty and a comment saying the tree-sitter CLI must be installed system-wide.

The TUI and the commands that sit next to it

The interface is a text user interface, opened with a single command, and the commands around it cover the whole lifecycle. The TSManager command opens the parser management interface, and the TSInstall command installs parsers given as arguments, with a synchronous variant that blocks until the installation finishes. TSUninstall removes parsers, and TSUpdate updates them, where adding a bang forces the update of everything rather than the ones named. The synchronous variants exist for both install and update, which tells you the author expected people to script around the command line. Inside the TUI the keybindings are the ones you would expect from a list of parsers. The i key installs the parser under the cursor, x removes it, u updates it, r refreshes the installation status, and q or escape closes the window. The status refresh is the useful one, because a parser build can fail and you want to see that without leaving the list. The interface is configurable in appearance, with a Nerd Font toggle, a border style and minimum width and height.

Two lists decide what happens when you open a file

The behaviour that changes your day is the automatic install, and the configuration around it is worth reading carefully because the defaults are conservative. The auto_install option is false by default, and turning it on installs missing parsers when you open a new file, with a noauto_install list to opt out of specific languages. The example given for the opt-out list is instructive, since it names c, lua, markdown, markdown_inline, query, vim and vimdoc, and the comment explains that these are the built-in Neovim Tree-sitter parsers, meaning the ones Neovim already ships and that you have no reason to rebuild. There is a parallel pair of options for highlighting, where the highlight option is true by default and can be given a list to whitelist, and the nohighlight option is a blacklist for specific languages to fall back to standard regex highlighting. The examples are a yaml and zsh opt-out for the regex route and a lua and c whitelist for the opt-in route. Three lists in total, and the ensure_installed option adds a fourth, being the parsers to install at startup.

Forks and new languages through the setup table

The extensibility story is the setup function and the languages table, and the readme is explicit that this keeps the plugin repository clean with no changes needed to the plugin itself. There are two shapes of customisation. You can override a built-in language definition to point at a fork, and the example shows a cpp entry with an install_info block giving a url, a revision and a queries path, so you can pin a specific commit of your own fork rather than tracking the default. You can also add a language that is not in the built-in list at all, with a mylang entry pointing at a repository and its queries directory. The queries option has its own documented behaviour, which is the detail that trips people up. If queries is unset or nil, the bundled runtime/queries directory for that language is symlinked into the query directory, so the highlights that ship with the plugin are used. Set it to the relative path of the queries directory in the repository, often just queries, and the queries shipped in the parser repository are used instead. The plugin then copies the chosen queries into the query directory so Neovim's runtime picks them up.

Inherited data, a testing setup and the known gaps

Two pieces of the plugin are inherited from the archived project, and the documentation is upfront about both. The syntax highlighting queries, the highlights.scm and injections.scm files, were sourced from the archived nvim-treesitter repository and placed in the runtime directory, and the parser repository URLs in the file holding the language definitions come from the same place. The warning attached to the URLs is the one to read, because it says they are provided as-is and that due to the large number of parsers each URL cannot be manually verified for current availability or compatibility, and asks for an issue or a pull request when one is broken, outdated or fails to build. The known limitations section lists three. Development is Unix-first, primarily tested on macOS and Linux, with Windows possibly needing additional testing. The tree-sitter CLI must be on the path. And there are no auto-updates, so a parser is updated manually with the update key or removed and reinstalled. The test setup uses the mini.nvim testing framework, downloaded by the Makefile and run headless, with an update-parsers target for refreshing the bundled parsers.

Editorial conclusion

tree-sitter-manager.nvim is a good fit for a Neovim 0.12 user who needs a working parser for a language, who has the tree-sitter CLI and a C compiler on the machine, and who would rather not depend on an archived plugin. It is the wrong tool if you only use the parsers that ship with Neovim itself, since the built-in set covers the common cases and the plugin explicitly offers to leave those alone, and it is the wrong tool if you cannot run the tree-sitter CLI, because the plugin shells out to it to build parsers. It is also the wrong tool if you expected parser updates to be automatic, since the documentation lists no auto-updates as a known limitation. Before adopting it, read the options block, because the auto-install and highlight lists are the two decisions that change your editor's behaviour, and check the parser links caveat, since the repository URLs are inherited from the archived plugin and are provided as-is. The plugin is MIT licensed, the last push was on 2026-10-17, and the current release is v1.0.1 from 2026-08-23.

Frequently asked questions

Why did tree-sitter-manager.nvim come into existence?

Because although Neovim 0.12 integrated Tree-sitter into the core, it still lacks a built-in parser installer, and with nvim-treesitter now archived the plugin provides a lightweight, actively maintained alternative for installing parsers and adding new languages.

What does tree-sitter-manager.nvim need installed to work?

Neovim 0.12 or later, the tree-sitter CLI, git for cloning the parser repositories, and a C compiler, either gcc or clang, for building the parsers. A Nerd Font is optional and is needed for the interface icons to display properly, and the lazy.nvim snippet notes that the tree-sitter CLI must be installed system-wide.

How do I point tree-sitter-manager.nvim at a fork of a language parser?

Use the languages option in setup with an entry for the language name containing an install_info block with a url, a revision and a queries path, which lets you pin a specific commit of your own fork. You can also add a language that is not in the built-in list the same way, and neither requires changes to the plugin repository.

What commands does tree-sitter-manager.nvim provide?

TSManager opens the parser management interface, TSInstall and TSInstallSync install parsers given as arguments with the synchronous variant blocking, TSUninstall removes parsers, and TSUpdate and TSUpdateSync update them, where adding a bang forces an update of everything. Inside the interface, i installs, x removes, u updates and r refreshes the status of the parser under the cursor.

Are the parser links in tree-sitter-manager.nvim reliable?

They are provided as-is, inherited from the archived nvim-treesitter repository, and the documentation warns that due to the large number of parsers each URL cannot be manually verified for current availability or compatibility. Broken links, outdated revisions and build failures are meant to be reported as an issue or fixed with a pull request, and the known limitations also list the absence of auto-updates for parsers.

Official sources

  1. Issues
  2. License: MIT
  3. README
  4. Releases
  5. romus204/tree-sitter-manager.nvim on GitHub
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/romus204-tree-sitter-manager-nvim.svg)](https://hysenlabs.com/projects/romus204-tree-sitter-manager-nvim)

Was this useful?