3 ms·
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/jo
by ivanjermakov 6mo ago
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/1621 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 6mo agoManaging 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 6mo agoQueries 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 https://github.com/ivanjermakov/hat-tree-sitter
- thayne 6mo agoI 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)