* scripts being poorly documented: what's the point of having a script if no one knows how to use it
* scripts going stale: often built by one person / an infra team. When they break, no one knows how to fix them
* creating scripts: bash isn't the most popular language these days, but it's still supported just about everywhere. How can we make building them easier and faster but still just as powerfulTree-sitter is more general: it aims to provide support for many languages and so its bash support is lacking a little. But it's very fast. It's designed for IDEs (hence why bash-lsp is using it). It caches its results and only re-parses on newly changed code blocks.
sh by mvdan and shellcheck are both built specifically for the shell. They both have really robust grammar. shellcheck is great for error handling. sh is great for building ASTs (it's more of a true parser)
As always, it depends on your use case. If you need a descriptive summary of errors / warnings in a shell script and performance isn't crucial, use shellcheck. If you need a really robust parser and AST output, use sh. If performance is crucial and/or you eventually want to support different languages, use tree-sitter.
Please feel free to jump in if I am wrong here!
This is built on tree-sitter, but there are a couple of other interesting shell parser projects:
At Fig (https://withfig.com), we had to write a bash parser from scratch. These projects all work well in the IDE context, but in a repl environment (ie when typing in your terminal) they don't support incomplete commands very well. e.g if I type `echo "$(` the above parsers will break as the double quote and parentheses are not closed.