Solargraph: Version 0.33.0

Created on 15 May 2019  路  9Comments  路  Source: castwide/solargraph

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.

Enhanced closure support

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

Deprecated plugin architecture

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.

enhancement

Most helpful comment

Released v0.33.0.

All 9 comments

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:

image

image

image

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

ymeaiqiLJl

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:

  • Recommend and/or generate @return tags from inferred method types
  • Flag unrecognized method calls
  • Flag method arguments that appear to be the wrong type
  • Generate reports about a project's type safety
  • Enforce a baseline of type safety in tests, git hooks, CI, etc.

I'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.

Was this page helpful?
0 / 5 - 0 ratings