6 ms·

Development tools like this with an obscene amount of dependencies, not to mention multi-language dependencies, is extremely worrying and irresponsible for the

Development tools like this with an obscene amount of dependencies, not to mention multi-language dependencies, is extremely worrying and irresponsible for the future of software development. Especially since they're not even native to bash's environment! If you would have told me 5 years ago I'd need to install node and typescript in order to get auto completion for bash, I'd have called you crazy. Yet here we are.

nicoburns 6y ago
What do you expect a bash language server to be written in? Bash?
- mdip 6y ago
  You said it, sarcastically, but that didn't mean I didn't think it. At first blush it sounds a little crazy, but the more I think about it... Consider my problem: I use `zsh` and have created, collected and organized a large number of completions which I synchronize among several workstations. It frustrates me to no end that I cannot take advantage of these completions in very many other convenient places, like VSCode[0]. The benefit of writing it in `zsh` (I can't speak for bash) is that seems like it'd be pretty simple to wire up the LSB as a sort of "completions proxy" that simply takes the inputs, passes them to a completion script, parses the output and formats it in the appropriate JSON response. The utility of being able to have a single script (or set of scripts) that I can include in my shared profile directory which will run and handle a `zsh` LSB implementation on-demand (i.e. doesn't need installing, sits in my scripts directory and runs everywhere) would be a huge feature. This will speak to my ignorance, but can you host a web server (in a manner that can be consumed) from just bash and a lean environment[1]? Could you host an LSP without one (i.e. is there enough to use a socket and would it be enough to point it at the right place/scheme?). I believe there are `zsh` extensions which can facilitate some/all of this, but I'm not sure if it would work out of the box. The downside to developing it in `zsh`, other than the language itself[2] is performance. Both of those, assuming "the hosting/serving" can be handled easily, don't represent big problems, maybe they are. But performance and the language should be up to what remains outside of that. [0] I had `nvim` set up correctly, once to work with completion scripts and was able to translate that into VSCode doing the same, about two years ago. I'm still not fully convinced I didn't just dream this up because the few times I've looked into it, since, I've gotten nowhere (admittedly, I've put little effort into researching). [1] I'm thinking 'busybox', minimal gnu-related things, ideally requiring as little as possible beyond a relatively recent version of `bash` so that "if it's got bash, I can use it". [2] I use `zsh` because it's easier for me to write things in it than `bash`, and at times it can be fun. But there's a reason we don't build solutions using it. [3] Everything's a string...
- crvdgc 6y ago
  Well, at least when writing that lsp, you have this lsp to help.
TechBro8615 6y ago
You can always tell who hasn’t used a tool because they leave comments like this. Same thing with complaints about node_modules. Anyone who’s actually worked with frontend tooling knows it’s light years ahead of the tooling in most backend languages. The developer experience out of the box with TypeScript + VSCode + Next.js is 1000x better than any stack I’ve ever worked with in Python, for example. So what if you need to pull in some dependencies? At least I don’t need to figure out what the best way to setup a Python environment is this month. (In fact, the current Python package manager du juor, Poetry, took most of its ideas from what Yarn implemented five years ago.) And what’s this about being irresponsible? You can easily pin your dependencies, use a lockfile, and even bake the cache into your Docker images. There’s no reason you can’t have a program that will run the same in two years as it does now. And setting that up is a lot easier than it is with other languages.
- tasogare 6y ago
  > Anyone who’s actually worked with frontend tooling knows it’s light years ahead of the tooling in most backend languages. The developer experience out of the box with TypeScript + VSCode + Next.js is 1000x better than any stack You should practice your April fools jokes to be less obvious, that post is not gonna make it.
- rowanG077 6y ago
  Are you serious? About a third of my job is frontend with typescript. The rest is backend and some application dev and embedded. Frontend is seriously the worst environment. It's great if the magic works. But that's the easy part. Once something breaks, and it will, you have to descend to the seventh circle of hell to figure out where something in this mount everest of tooling and dependencies broke. I love the idea of frontend dev. But the tooling takes all of the fun out of it.
  - mdip 6y ago
    But I don't think your problems with FE Dev/TypeScript are "TypeScript" problems so much as they're problems around the tooling you're using with `node`. And I agree. Unless it works out of the box, it's a half-day of profanity at least. But writing a command-line tool in TypeScript doesn't require any of that. The comment focused on FE development with Next.js -- I have no experience with that, but a simple React-based solution using `create-react-app` works out-of-the-box for a lot of things[0]. I will say, it does sometimes feel like everything TypeScript gets right is made up for by everything "all of the bundlers/tooling around it" screws up, but it's gotten monumentally better. You're always going to be weighing pain points against eachother, and folks that do front-end web development all day long are going to find the problems they routinely encounter to be "simple", possibly even "intuitive" based on how the rest of the ecosystem works. From my perspective -- partly on the inside, partly on the outside -- I seem to have to muck around with the equivalent of "build scripts" about as often as I used to (not) enjoy in the C/C++-land. But dammit-all if "time to completely working" in TypeScript isn't always twice as quick. TypeScript, configured correctly, catches so many run-time issues at compile-time[1]. For me, the distance between "it runs" and "it runs correctly" is often shorter in TypeScript despite it not being my primary language. [0] To be sure, it's hard for me to say `create-react-app` without the obligatory `fscking` inserted... it's got many problems, but at least half the time it's an implementation detail. [1] Static-type-checking time?
michael1999 6y ago
Do you really think someone would write a lexer, a parser, and an implementation of the LSP protocol for Bash in Bash?
- usbline 6y ago
  There's more languages native to unix-land than Bash, you know. Find me a linux distro that doesn't have GCC or Clang installed by default, or even Python for that matter.
  - mikewhy 6y ago
    What about C and Python are "native to Bash's environment" though? That's the complaint the person you're responding to is touching on. Also, lots of Linux distributions don't come with GCC and Clang by default (Ubuntu, Debian, OpenSUSE).
    - akvadrako 6y ago
      Bash is written in C so depending on C doesn't add a dependency. Python is also the 2nd most popular scripting language in the Linux world; it's even part of the Freedesktop base runtime. Though I don't know if it's standard in BSDs.
  - oblio 6y ago
    > Find me a linux distro that doesn't have GCC or Clang installed by default Most distros don't preinstall C compilers.
- kazinator 6y ago
  But there is a lexer and parser for Bash inside Bash. Bash could either provide the LSP protocol itself, or else open up some primitives for a script to gain access to the info somehow.
delusional 6y ago
It also means that your text editor is now a distributed system.
methyl 6y ago
> Development tools like this with an obscene amount of dependencies, not to mention multi-language dependencies, is extremely worrying and irresponsible for the future of software development Care to elaborate why?
- usbline 6y ago
  >Care to elaborate why? Not particularly, since it'll only fall on deaf ears considering HN's demographic.
  - methyl 6y ago
    So you want to tell, it's better to have no tool at all (given pre-tree-sitter Bash LSP doesn't exist), than to have a tool with a lot of dependencies? I get that some may avoid having huge number of dependencies on production, but when it comes to local development tools, I couldn't care less. It's 2021, I can buy 1 TB SSD for less than 100 bucks.
    - kazinator 6y ago
      You maybe able to buy a TB SSD for < $100, but you can't make sense of the ball of mud that is on it.
  - deleted 6y ago
    [deleted]
mikewhy 6y ago
> If you would have told me 5 years ago I'd need to install node and typescript in order to get auto completion for bash, I'd have called you crazy. This line right here means there's no runtime dependencies https://github.com/bash-lsp/bash-language-server/blob/fa5a65e1a00c663758cfb7ac153e830fda5b4743/package.json#L34 https://github.com/bash-lsp/bash-language-server/blob/fa5a65... edit: turns out there are runtime dependencies (see child comments). Still, typescript is not one of them.
- usbline 6y ago
  Node is not a runtime now? :)
  - mikewhy 6y ago
    No more than Bash :):):) And either way, you don't need TypeScript to run this language server. You just need node. If you're not happy with that, well, consider this repo a reference and get cracking.
- dvlsg 6y ago
  I think there are runtime dependencies, just not at the root level of the repo. https://github.com/bash-lsp/bash-language-server/blob/fa5a65e1a00c663758cfb7ac153e830fda5b4743/server/package.json#L21 https://github.com/bash-lsp/bash-language-server/blob/fa5a65...
  - mikewhy 6y ago
    Ah, nice catch. I'll revise my comment.
- kazinator 6y ago
  Doesn't TypeScript work by transpilation to JavaScript? In which case, it is never a run-time dependency; JavaScript is.
brobdingnagians 6y ago
I like minimalism, I agree with cutting down dependencies, but the person who does the work gets to pick the language. If I did it, I'd do it in C, Rust, or Kotlin, but I appreciate having an LSP for a new language nonetheless. Looks like it has no runtime library dependencies, then that removes risk of supply chain issues, so I think they've done a good job.
stevenhuang 6y ago
Yeah. When I gave this a shot a while back, I looked at its dependencies and it was way larger than the footprint of coc-clangd for some reason. Wasn't a good signal so decided to remove it after that.
- mikewhy 6y ago
  clangd is already a language server, so coc-clangd can be small since it only needs to be a bridge between the two.
  - stevenhuang 6y ago
    That makes sense. I'll likely revisit this plugin then, thanks.
brundolf 6y ago
I look forward to your dependency-free implementation!
tester756 6y ago
on the other hand... software is so modular nowadays that you can write language-server in C#, for an Typescript IDE/Editor that helps you to write Bash scripts for Linux.
cle 6y ago
Node and TypeScript have the best Language Server tooling, because that is what Microsoft uses for VS Code.
- ttt0 6y ago
  "JavaScript is the best language for writing HTTP servers, because that is what web browsers use." Doesn't make any sense. LSP is just a protocol. You can write language servers in whatever language you want.
  - kazinator 6y ago
    But, look at this project. They took a Bash parser written in C from the Tree-sitter project, and are using the C as a compiled WebAssembly blob out of TypeScript. And, actually, that Tree-sitter Bash parser is specified or generated using JS somehow; the project for producing it uses TypeScript also. That's how easy it is to write LSP server in any language? Maybe it's done this way so that the LSP can be integrated right into the editor itself, so as not to have to run somewhere else as an external piece.
  - cle 6y ago
    What are you talking about? TypeScript has the best Language Server libraries, if you want maximum productivity when making a Language Server, you run with TypeScript. I don't even like TypeScript but I can at least acknowledge that it can make sense to implement a Language Server in it. Personally I would have used Go for this exact reason, but it's reasonable to use TypeScript too.
nikolay 6y ago
YARGM (Yet Another Rube Goldberg Machine)
deleted 6y ago
[deleted]
fouric 6y ago
> irresponsible for the future of software development Not true. This is highly interchangeable tooling - it can have whatever dependencies you want, because there's no "dependency explosion" that happens with libraries. LSP is a standardized protocol - you can swap it out with anything you like. Moreover, people rarely build interactive tools on top of other interactive tools. Now, if this were a library with a bunch of dependencies, that would be a whole different matter - then any program or library that used this would get all of the transitive dependencies - but, it's not. Go and reimplement this tool yourself. RIIR, make a statically-linked 500kb executable with no perceptual execution time, and eat their lunch, because your tool is a drop-in replacement. Is a Node dependency a bad idea for this tool? Arguably yes. Is it "irresponsible for the future of software development"? That statement is so false that I suspect it's being used to try to emotionally manipulate readers instead of making a coherent argument. Also...are you aware that Bash already tab-completion, even if it's not automatic? I'm beginning to wonder if this is a very subtle April Fool's post...
kazinator 6y ago
> node and typescript in order to get auto completion for bash, I'd have called you crazy It's worse than you think. This uses something called Tree-sitter: some project written in C for providing parsers for numerous languages. The Tree-sitter parser for Bash itself somehow requires Typescript, though the parser is in C. This Bash-LSP project uses a binary blob of that parser: it is C compiled as C++ into WebAssembly. Bash-LSP, as well as the Tree-sitter Bash parser, can basically be called IDE tooling written by and for TypeScript programmers, who sometimes have to mess with Bash scripts. The target audience doesn't mind TypeScript and Node dependencies, and in fact likely finds that preferrable to any other kind of dependency, because working with TypeScript dependencies is fresh in their minds, requiring little ramp-up to handle another one.
- nonbirithm 6y ago
  > The Tree-sitter parser for Bash itself somehow requires Typescript, though the parser is in C. This is not necessarily true if you can write a compiler for a tree-sitter grammar that outputs the parser code in your favorite language. I know semgrep does this to make parsers for OCaml. But, of course, that's more work to be done.
- jussij 6y ago
  > The Tree-sitter parser for Bash itself somehow requires Typescript, though the parser is in C. You can use tree-sitter to produce nothing more than C parser file that only depends on a very small tree-sitter C library. So you can use tree-sitter to produce a parser that does not require Typescript. However, there is whole other side to tree-sitter which is about filtering/manipulating/searching the AST results produced by that C parser and this layer has binding to many languages. I suspect this Bash LSP project is using the tree-sitter Typescript bindings for their AST processing.
gkfasdfasdf 6y ago
This is an interesting criticism. So a bash language server must be written in bash? I think that would be indeed be a software dev monstrosity.

nicoburns 6y ago

What do you expect a bash language server to be written in? Bash?

mdip 6y ago
You said it, sarcastically, but that didn't mean I didn't think it. At first blush it sounds a little crazy, but the more I think about it... Consider my problem: I use `zsh` and have created, collected and organized a large number of completions which I synchronize among several workstations. It frustrates me to no end that I cannot take advantage of these completions in very many other convenient places, like VSCode[0]. The benefit of writing it in `zsh` (I can't speak for bash) is that seems like it'd be pretty simple to wire up the LSB as a sort of "completions proxy" that simply takes the inputs, passes them to a completion script, parses the output and formats it in the appropriate JSON response. The utility of being able to have a single script (or set of scripts) that I can include in my shared profile directory which will run and handle a `zsh` LSB implementation on-demand (i.e. doesn't need installing, sits in my scripts directory and runs everywhere) would be a huge feature. This will speak to my ignorance, but can you host a web server (in a manner that can be consumed) from just bash and a lean environment[1]? Could you host an LSP without one (i.e. is there enough to use a socket and would it be enough to point it at the right place/scheme?). I believe there are `zsh` extensions which can facilitate some/all of this, but I'm not sure if it would work out of the box. The downside to developing it in `zsh`, other than the language itself[2] is performance. Both of those, assuming "the hosting/serving" can be handled easily, don't represent big problems, maybe they are. But performance and the language should be up to what remains outside of that. [0] I had `nvim` set up correctly, once to work with completion scripts and was able to translate that into VSCode doing the same, about two years ago. I'm still not fully convinced I didn't just dream this up because the few times I've looked into it, since, I've gotten nowhere (admittedly, I've put little effort into researching). [1] I'm thinking 'busybox', minimal gnu-related things, ideally requiring as little as possible beyond a relatively recent version of `bash` so that "if it's got bash, I can use it". [2] I use `zsh` because it's easier for me to write things in it than `bash`, and at times it can be fun. But there's a reason we don't build solutions using it. [3] Everything's a string...
crvdgc 6y ago
Well, at least when writing that lsp, you have this lsp to help.

TechBro8615 6y ago

You can always tell who hasn’t used a tool because they leave comments like this. Same thing with complaints about node_modules. Anyone who’s actually worked with frontend tooling knows it’s light years ahead of the tooling in most backend languages. The developer experience out of the box with TypeScript + VSCode + Next.js is 1000x better than any stack I’ve ever worked with in Python, for example. So what if you need to pull in some dependencies? At least I don’t need to figure out what the best way to setup a Python environment is this month. (In fact, the current Python package manager du juor, Poetry, took most of its ideas from what Yarn implemented five years ago.) And what’s this about being irresponsible? You can easily pin your dependencies, use a lockfile, and even bake the cache into your Docker images. There’s no reason you can’t have a program that will run the same in two years as it does now. And setting that up is a lot easier than it is with other languages.

tasogare 6y ago
> Anyone who’s actually worked with frontend tooling knows it’s light years ahead of the tooling in most backend languages. The developer experience out of the box with TypeScript + VSCode + Next.js is 1000x better than any stack You should practice your April fools jokes to be less obvious, that post is not gonna make it.
rowanG077 6y ago
Are you serious? About a third of my job is frontend with typescript. The rest is backend and some application dev and embedded. Frontend is seriously the worst environment. It's great if the magic works. But that's the easy part. Once something breaks, and it will, you have to descend to the seventh circle of hell to figure out where something in this mount everest of tooling and dependencies broke. I love the idea of frontend dev. But the tooling takes all of the fun out of it.
- mdip 6y ago
  But I don't think your problems with FE Dev/TypeScript are "TypeScript" problems so much as they're problems around the tooling you're using with `node`. And I agree. Unless it works out of the box, it's a half-day of profanity at least. But writing a command-line tool in TypeScript doesn't require any of that. The comment focused on FE development with Next.js -- I have no experience with that, but a simple React-based solution using `create-react-app` works out-of-the-box for a lot of things[0]. I will say, it does sometimes feel like everything TypeScript gets right is made up for by everything "all of the bundlers/tooling around it" screws up, but it's gotten monumentally better. You're always going to be weighing pain points against eachother, and folks that do front-end web development all day long are going to find the problems they routinely encounter to be "simple", possibly even "intuitive" based on how the rest of the ecosystem works. From my perspective -- partly on the inside, partly on the outside -- I seem to have to muck around with the equivalent of "build scripts" about as often as I used to (not) enjoy in the C/C++-land. But dammit-all if "time to completely working" in TypeScript isn't always twice as quick. TypeScript, configured correctly, catches so many run-time issues at compile-time[1]. For me, the distance between "it runs" and "it runs correctly" is often shorter in TypeScript despite it not being my primary language. [0] To be sure, it's hard for me to say `create-react-app` without the obligatory `fscking` inserted... it's got many problems, but at least half the time it's an implementation detail. [1] Static-type-checking time?

michael1999 6y ago

Do you really think someone would write a lexer, a parser, and an implementation of the LSP protocol for Bash in Bash?

usbline 6y ago
There's more languages native to unix-land than Bash, you know. Find me a linux distro that doesn't have GCC or Clang installed by default, or even Python for that matter.
- mikewhy 6y ago
  What about C and Python are "native to Bash's environment" though? That's the complaint the person you're responding to is touching on. Also, lots of Linux distributions don't come with GCC and Clang by default (Ubuntu, Debian, OpenSUSE).
  - akvadrako 6y ago
    Bash is written in C so depending on C doesn't add a dependency. Python is also the 2nd most popular scripting language in the Linux world; it's even part of the Freedesktop base runtime. Though I don't know if it's standard in BSDs.
- oblio 6y ago
  > Find me a linux distro that doesn't have GCC or Clang installed by default Most distros don't preinstall C compilers.
kazinator 6y ago
But there is a lexer and parser for Bash inside Bash. Bash could either provide the LSP protocol itself, or else open up some primitives for a script to gain access to the info somehow.

delusional 6y ago

It also means that your text editor is now a distributed system.

methyl 6y ago

> Development tools like this with an obscene amount of dependencies, not to mention multi-language dependencies, is extremely worrying and irresponsible for the future of software development Care to elaborate why?

usbline 6y ago
>Care to elaborate why? Not particularly, since it'll only fall on deaf ears considering HN's demographic.
- methyl 6y ago
  So you want to tell, it's better to have no tool at all (given pre-tree-sitter Bash LSP doesn't exist), than to have a tool with a lot of dependencies? I get that some may avoid having huge number of dependencies on production, but when it comes to local development tools, I couldn't care less. It's 2021, I can buy 1 TB SSD for less than 100 bucks.
  - kazinator 6y ago
    You maybe able to buy a TB SSD for < $100, but you can't make sense of the ball of mud that is on it.
- deleted 6y ago
  [deleted]

mikewhy 6y ago

> If you would have told me 5 years ago I'd need to install node and typescript in order to get auto completion for bash, I'd have called you crazy. This line right here means there's no runtime dependencies https://github.com/bash-lsp/bash-language-server/blob/fa5a65e1a00c663758cfb7ac153e830fda5b4743/package.json#L34 https://github.com/bash-lsp/bash-language-server/blob/fa5a65... edit: turns out there are runtime dependencies (see child comments). Still, typescript is not one of them.

usbline 6y ago
Node is not a runtime now? :)
- mikewhy 6y ago
  No more than Bash :):):) And either way, you don't need TypeScript to run this language server. You just need node. If you're not happy with that, well, consider this repo a reference and get cracking.
dvlsg 6y ago
I think there are runtime dependencies, just not at the root level of the repo. https://github.com/bash-lsp/bash-language-server/blob/fa5a65e1a00c663758cfb7ac153e830fda5b4743/server/package.json#L21 https://github.com/bash-lsp/bash-language-server/blob/fa5a65...
- mikewhy 6y ago
  Ah, nice catch. I'll revise my comment.
kazinator 6y ago
Doesn't TypeScript work by transpilation to JavaScript? In which case, it is never a run-time dependency; JavaScript is.

brobdingnagians 6y ago

I like minimalism, I agree with cutting down dependencies, but the person who does the work gets to pick the language. If I did it, I'd do it in C, Rust, or Kotlin, but I appreciate having an LSP for a new language nonetheless. Looks like it has no runtime library dependencies, then that removes risk of supply chain issues, so I think they've done a good job.

stevenhuang 6y ago

Yeah. When I gave this a shot a while back, I looked at its dependencies and it was way larger than the footprint of coc-clangd for some reason. Wasn't a good signal so decided to remove it after that.

mikewhy 6y ago
clangd is already a language server, so coc-clangd can be small since it only needs to be a bridge between the two.
- stevenhuang 6y ago
  That makes sense. I'll likely revisit this plugin then, thanks.

brundolf 6y ago

I look forward to your dependency-free implementation!

tester756 6y ago

on the other hand... software is so modular nowadays that you can write language-server in C#, for an Typescript IDE/Editor that helps you to write Bash scripts for Linux.

cle 6y ago

Node and TypeScript have the best Language Server tooling, because that is what Microsoft uses for VS Code.

ttt0 6y ago
"JavaScript is the best language for writing HTTP servers, because that is what web browsers use." Doesn't make any sense. LSP is just a protocol. You can write language servers in whatever language you want.
- kazinator 6y ago
  But, look at this project. They took a Bash parser written in C from the Tree-sitter project, and are using the C as a compiled WebAssembly blob out of TypeScript. And, actually, that Tree-sitter Bash parser is specified or generated using JS somehow; the project for producing it uses TypeScript also. That's how easy it is to write LSP server in any language? Maybe it's done this way so that the LSP can be integrated right into the editor itself, so as not to have to run somewhere else as an external piece.
- cle 6y ago
  What are you talking about? TypeScript has the best Language Server libraries, if you want maximum productivity when making a Language Server, you run with TypeScript. I don't even like TypeScript but I can at least acknowledge that it can make sense to implement a Language Server in it. Personally I would have used Go for this exact reason, but it's reasonable to use TypeScript too.

nikolay 6y ago

YARGM (Yet Another Rube Goldberg Machine)

deleted 6y ago

[deleted]

fouric 6y ago

> irresponsible for the future of software development Not true. This is highly interchangeable tooling - it can have whatever dependencies you want, because there's no "dependency explosion" that happens with libraries. LSP is a standardized protocol - you can swap it out with anything you like. Moreover, people rarely build interactive tools on top of other interactive tools. Now, if this were a library with a bunch of dependencies, that would be a whole different matter - then any program or library that used this would get all of the transitive dependencies - but, it's not. Go and reimplement this tool yourself. RIIR, make a statically-linked 500kb executable with no perceptual execution time, and eat their lunch, because your tool is a drop-in replacement. Is a Node dependency a bad idea for this tool? Arguably yes. Is it "irresponsible for the future of software development"? That statement is so false that I suspect it's being used to try to emotionally manipulate readers instead of making a coherent argument. Also...are you aware that Bash already tab-completion, even if it's not automatic? I'm beginning to wonder if this is a very subtle April Fool's post...

kazinator 6y ago

> node and typescript in order to get auto completion for bash, I'd have called you crazy It's worse than you think. This uses something called Tree-sitter: some project written in C for providing parsers for numerous languages. The Tree-sitter parser for Bash itself somehow requires Typescript, though the parser is in C. This Bash-LSP project uses a binary blob of that parser: it is C compiled as C++ into WebAssembly. Bash-LSP, as well as the Tree-sitter Bash parser, can basically be called IDE tooling written by and for TypeScript programmers, who sometimes have to mess with Bash scripts. The target audience doesn't mind TypeScript and Node dependencies, and in fact likely finds that preferrable to any other kind of dependency, because working with TypeScript dependencies is fresh in their minds, requiring little ramp-up to handle another one.

nonbirithm 6y ago
> The Tree-sitter parser for Bash itself somehow requires Typescript, though the parser is in C. This is not necessarily true if you can write a compiler for a tree-sitter grammar that outputs the parser code in your favorite language. I know semgrep does this to make parsers for OCaml. But, of course, that's more work to be done.
jussij 6y ago
> The Tree-sitter parser for Bash itself somehow requires Typescript, though the parser is in C. You can use tree-sitter to produce nothing more than C parser file that only depends on a very small tree-sitter C library. So you can use tree-sitter to produce a parser that does not require Typescript. However, there is whole other side to tree-sitter which is about filtering/manipulating/searching the AST results produced by that C parser and this layer has binding to many languages. I suspect this Bash LSP project is using the tree-sitter Typescript bindings for their AST processing.

gkfasdfasdf 6y ago

This is an interesting criticism. So a bash language server must be written in bash? I think that would be indeed be a software dev monstrosity.