Allow users to configure the extension

[xeger]

(NB: this is a branch off of registerOnce which blocks clean restart of the LSP, as needed here. Will change base branch & set ready for review once that gets merged.)

Goal: uninstall the all-in-one rebornix.ruby; instead, use Syntax Tree, Solargraph and the confusingly-named VSCode Ruby coloring/tokenzing extension to provide blurry-fast, efficient language services

As soon as this extension is personally useful to me, I'll introduce it to my workplace which will recruit 30-50 beta testers to give me feedback. I may end up simply adding Syntax Tree support to rebornix.ruby and perhaps offer other help to its weary maintainer; even so, an independent Syntax Tree extension is helpful.

[kddnewton]

This looks really good. Looking forward to merging this. Just one question on the other PR.

[kddnewton]

@xeger is this ready to come out of draft mode?

[xeger]

Yup! I did some basic testing this morning to verify the auto-restart behavior. Ready for any feedback you have on UX considerations.

At some point I'll probably need to expose a RUBYOPT tweaker configuration, but that'll come down the road, if I end up needing custom plugins within my dev org. (Hoping to avoid.)

[xeger]

One thing I did encounter during testing, is "interesting" behavior with multi-root workspaces.

In a monorepo, there may be many Gemfiles - and it's not a guarantee there will be a Gemfile at any or all of the workspace roots. If our goal is to invoke the bundled syntax_tree when one is available, it gets very complex to do that right. (And the LSP is a singleton, so there is no single right choice.)

Moreover, this extension relies on CLI parameters of the stree exe -- there's no guarantee that the gem version in some bundle, or even in the system, will be compatible with the CLI that this extension expects (v1/v2 upgrade type scenario).

The workaround is to install a system gem, or to add a Gemfile at the 0th workspace root specifically for syntax_tree. So, not a blocker to adoption. If usage of this extension really takes off, I'll give some more thought to it.

[kddnewton]

Ugh, you're totally right. It's the same issue I've run into countless times with prettier.

In reality I think the only completely error-proof way to do this would be to literally bundle ruby itself into the extension. And obviously we're not going to do that.

[kddnewton]

@xeger I spent some time updating the extension tonight to bump the dependencies and add some very very minimal CI which just compiles the extension. Turns out testing these extensions is really hard. Would you mind testing the main branch on your machine as well?

If all is well, I can release a new version of this extension.

[xeger]

Tested the four commands, checkbox settings, and also tested in my monorepo to ensure the workarounds still work. Looking pretty good @kddnewton.

I identified a new bug: I had a file that didn't exist on disk yet but which I'd named (e.g. invoked code foo.rb in empty tmpdir). The LSP crashed 5x in succession and was summarily paused by the IDE. Looked like a Ruby backtrace in someone's stdout, so it's probably a simple matter of rescue ENOENT somewhere. Worth opening a ticket?

[xeger]

Re bundling Ruby into an extension, traversing parent dirs until we find a .(ruby|tool)_versions? and shimming the right bin dir into our path will let us invoke the right Ruby (with rbenv or asdf - unsure how to do that with rvm). Bundler or not can be decided orthogonally, and should work with cwd either at the nearest Gemfile-having parent, or possibly with cwd underneath that (I think Bundler does its own traversal).

You'd still need a separate LSP for each "runtime root" in the workspace, plus a multi-dispatch thing; it would not be fun to code, and definitely merits a whole passel of automated tests. Maybe if the extension takes over the world; until then, the simple workaround is sufficient. Can always add a path tweaker to the extension so people can aim at the right thing themselves. If we substitute variables like the main VS Code settings can do, it's probably sufficient for most peoples' needs.

[kddnewton]

@xeger yeah that's definitely a bug. I'm assuming the issue is here: https://github.com/ruby-syntax-tree/syntax_tree/blob/cc38cf4949a1937c6b1354639232f42a29a38233/lib/syntax_tree/language_server.rb#L26. I think it's assuming that a file will exist on disk if it's not already in the store. That's obviously incorrect in this case.

[xeger]

Opened an issue for the crash bug, and also for a UX enhancement for the extension. (Obviously I intend to fix these thingsin the near future; hopefully you don't mind me peppering the repos with open issues in the meantime.)

[kddnewton]

Not at all, I really appreciate the help!