I'm not convinced a parser reimplementation is the right approach here. My plan was rather to integrate with the real parser to provide diagnostics and to obtain information about symbols for completion and go-to functionality. A separate parser would mean extra work each time the grammar changes. So the language server would be independent from editors, but a VS Code plugin is an obvious target.

My overall goal with this is mostly to have some go-to editor setup we can generally recommend to people. I'm personally using vim and have already written syntax highlighting definitions for that. With a language server, I would improve my own setup as well.

>But there is a bash language server which uses tree-sitter.

For bash, a separate implementation makes more sense because bash itself parses and executes shell scripts line-by-line. There is no whole-file parsing that a language server implementation could leverage.

>Also, is there the allowed syntax somewhere documented?

We don't really have a syntax specification. The parser decides what's valid and what is not. However, for editor support, you always have the option to be more strict or more lenient that what's actually allowed. For example, most syntax highlighting implementations just match on individual constructs and don't understand the overall code structure. This makes the highlighting less precise, but allows highlighting incomplete snippets without extra effort.