Relation with Sorbet

[sunnyrjuneja]

Hello castwide! Big fan of this gem and been using it quite often. I'm curious, now that Sorbet is public, do you see any relationship between Sorbet / Solargraph?

https://sorbet.org/blog/2019/06/20/open-sourcing-sorbet

[castwide]

Thanks!

Sorbet came to my attention a few months ago. Glad to see they've started open-sourcing it. A relationship between Sorbet and Solargraph is definitely a possibility. Some of the features overlap, and they have lots of potential to complement each other. A few preliminary thoughts:

• Solargraph 0.33.0 introduced a beta of its own static type checker (Static type checker #192). One important difference is that Solargraph uses YARD tags instead of code annotations.
• Solargraph could be extended to map Sorbet annotations and use them in the language server.
• If there isn't a tool for generating YARD tags from Sorbet annotations or vice versa, it might be worthwhile to make one.

[sunnyrjuneja]

@castwide great answer! i've been doing some more investigation myself and it feels the ecosystem around sorbet is pretty minimal (for example, i can't find any editor plugins). you've obviously done a fantastic job of developer ux so i hope there's a bit of overlap between the projects.

Also, I know you're working on rails integration (#87) here's some tooling around rails / sorbet coming out: https://github.com/chanzuckerberg/sorbet-rails.

[DarkDimius]

@sunnyrjuneja Sorbet actually has a LSP server inside it(pass --lsp on the command line) and thus should be easy to integrate if you were to try! Note that many lsp features are disabled by default and need to be enabled via command line flags(srb tc --help will show them all)

[DarkDimius]

Editor plugin exists but it's currently closed source. It will get open-sourced when we stabilize LSP features.

[minkir014]

@DarkDimius Is there a plugin for vs code???

[sunnyrjuneja]

@DarkDimius Thank you for the update! Looking forward to the open sourcing of the editor features. My CTO and I are already working on integrating Sorbet into our Rails application.

I've been closely tracking Twitter for updates on Sorbet and am extremely excited about the work you've released today. I'm so grateful for you and your team's hard work.

[minkir014]

@DarkDimius Are you here? Please answer my question above.

[sunnyrjuneja]

@minkir014 he answered your question, it's coming soon.

[connorshea]

@castwide FWIW, Sord is a tool for translating YARD docs into Sorbet signatures (and it works pretty well already): https://github.com/AaronC81/sord

It only works in one direction, though.

[guledali]

Man I which there was a way of converting rbi or Sorbet signatures files into YARD.

[amake]

I have been using Solargraph with Emacs's lsp-mode for a while and it's really great. Thank you for your hard work.

My team is now evaluating typechecking packages, and obviously Sorbet and Solargraph are on our list.

I am curious about the future of Solargraph's typechecking in light of the recent news about Ruby 3's type signature language:
https://developer.squareup.com/blog/the-state-of-ruby-3-typing/

I feel like I understand the roadmap for Sorbet and how it will fit into the bigger picture, but what about Solargraph? Are there plans to work with RBS in the future?

(Personally I like Solargraph's current YARD approach: it's unintrusive yet still readily visible, and an extension of what we were already doing. But it could be a tough sell for my org to double-down on this approach if external type definitions are truly the way of the future.)

[castwide]

@amake It definitely makes sense to support RBS if/when it becomes part of the Ruby standard, but I'm still not sure what form it should take. A few considerations:

• Keeping RBS and YARD in sync. When one or the other changes, which should be considered the authority?
• Automatically generating RBS files. This would somewhat fix the issue of authority, assuming a superficial similarity to how TypeScript works. Nonetheless, there are liable to be use cases where it isn't a good fit.
• IDE integration. When you want to jump to a method's definition, should it link to both the .rb and the .rbs? I'd prefer not, but there's bound to be disagreement from developers who roll their own RBS files.
• Ease of maintenance. I prefer maintaining the type annotations in the source, which is why I'm leaning toward canonical YARD and generated RBS. I also suspect the other direction (generating YARD from RBS) would be impractical; and manually writing both YARD and RBS would be excruciating.

[alexrecuenco]

The last update here was in 2020. I wonder if there any updates worth sharing in terms of the status of solargraph's RBS support at the moment

Since we have this on the README now

As of version 0.49.0, Solargraph uses rbs for core and stdlib documentation. The following only applies to prior versions.