The closure branch introduces a major refactoring of the Solargraph internals. Most of the changes are in the mapping processes to improve performance and accuracy. It also introduces enhanced closure support and deprecates the existing plugin architecture.
The new mapper has a deeper understanding of namespaces, scopes, and closures. Blocks can be rebound based on the context in which they are expected to run, e.g., a class_eval block:
class Foo
@bar = 'bar'
end
Foo.class_eval do
@bar # <- Recognized as a String
end
The plugin architecture has been removed completely. It never left the experimental stage and was already largely unused due to bugs and performance problems. If a .solargraph.yml configuration has a plugins section, it will simply be ignored.
A different version of plugins is a future possibility. In the meantime, the issues that plugins (esp. the runtime plugin) were intended to fix are partially mitigated by improved core documentation (#155) and more support for YARD directives like @!macro and @!parse.
Barring unforeseen bugs, I expect to release these changes in version 0.33.0.
Version 0.33.0 will also add an enhancement to type inference.
Solargraph first introduced deep type inference in 0.29.0. It enables maps to infer return types from methods without tags:
class Foo
def bar
@bar ||= []
end
end
Foo.new.bar # Return type of `bar` is recognized as Array
Version 0.33.0 includes the inferred types in hover info and completion item detail:



Go To Definition works on require paths. It should open files either on the local path or in a detected gem.

Solargraph first introduced deep type inference in 0.29.0. It enables maps to infer return types from methods without tags:
I wasn't aware of that. Makes me wonder if I can use solargraph for some static analysis. Currently I'm using rubocop for some - but it only gets you so far.
Solograph uses rubocop for linting and diagnostics
I'm working on more static analysis tools. Some of the features I'm exploring:
@return tags from inferred method typesI'm also looking at an option to generate gem documentation that adds inferred types to methods that don't have explicit @return tags.
Ultimately, I'd like Solargraph to provide the same types of features for Ruby that Flow and TypeScript provide for JavaScript, but without requiring any annotation besides YARD.
That sounds mighty interesting. One of the key things I wish I could do in static analysis was have better tracking of values beyond the direct scope they are used in. Right now I'm working around it by using fragile naming convention to infer what the code might do.
These tools you describe you are looking into, will they be in solargraph, or as other standalone tools?
That sounds mighty interesting. One of the key things I wish I could do in static analysis was have better tracking of values beyond the direct scope they are used in. Right now I'm working around it by using fragile naming convention to infer what the code might do.
Can you give me an example? I'm not sure what you mean.
These tools you describe you are looking into, will they be in solargraph, or as other standalone tools?
For now, I'm planning to make them part of Solargraph, since they share a lot of functionality with the language server. If it gets too unwieldy, I might split the mapping and static analysis libraries into a separate gem, which would simply become one of Solargraph's dependencies.
The closure branch is merged into master.
Released v0.33.0.
Most helpful comment
Released v0.33.0.