This is a bane of all such aggregator libraries, that suck maintetance from other projects into themself. Null-ls suffered from this, too: https://github.com/jose-elias-alvarez/null-ls.nvim/issues/16...

The source of a library needs an update every time there is a configuration change in _any_ tree-sitter parser supported.

The only sustainable option is not use these helpers and manage editor dependencies manually: tree-sitter parsers, LSP servers (looking at you Mason), and plugins (looking at you neovim distros).

▲

fredrikaverpil 19 hours ago | parent | next [-]

Managing the parsers yourself is fairly easy and could rely on running the tree-sitter CLI in each parser repo to build them. Other options exists like installing via Nix.

And in a similar vein, if queries (.scm files) were hosted in each parser repo, it would also be fairly easy to handle.

I think it’s the latter part with the query files that is the challenge here.

	▲	ivanjermakov 19 hours ago \| parent [-]
		Queries are a part of tree-sitter, but unfortunately neovim extended those with more predicates and operators, making most nvim-sitter incompatible with tree-sitter API. For my text editor I had to yank nvim-treesitter queries and rewrite them. https://github.com/ivanjermakov/hat-tree-sitter

▲

thayne 13 hours ago | parent | prev [-]

I think it would make a big difference even if the aggregation of queries was separated out into a separate repo from the other code, so that you can pin the code for installing and updating parsers while still being able to get updates to the queries, and it isn't as much of a problem if the installation code make major breaking changes (like requiring you to use 0.12)