Scanning Workspaces

The solargraph executable includes a scan command to look for code in your workspace that Solargraph can’t parse or map. In some cases, these problems can stop the language server from working properly.

Please note that scans are not very effective for identifying defects in your own code. A successful scan only confirms that Solargraph is able to analyze the workspace without crashing. It does not perform any validation of its analysis. When a scan fails, it’s more likely to indicate a bug in Solargraph itself than a problem with your code. If you’re interested in identifying type discrepancies or enforcing type safety, consider using the type checker instead.

From the command line:

$ cd /path/to/workspace
$ solargraph scan -v

The scan will perform a probe on every mapped snippet of code (called “pins”) in the workspace. The -v option tells it to output a line of information about every pin it finds. For the Solargraph codebase, the output looks something like this:

 |
Solargraph
Solargraph::ApiMap
Solargraph::ApiMap::Cache
Solargraph::ApiMap::Cache.new
Solargraph::ApiMap::Cache#initialize
Solargraph::ApiMap::Cache#initialize | @methods
Solargraph::ApiMap::Cache#initialize | @constants
# (several thousand lines truncated)
Scanned /solargraph (44246 pins) in 35.820807722979225 seconds.

Scans can take up to a few minutes to finish, depending on the size of the workspace. Either of the following results indicate a possible bug in Solargraph:

1. The scan throws an exception. The output should tell you the location in the workspace that caused the error.
2. The scan freezes on a pin. Each pin’s probe should only take a fraction of a second. If it takes any longer, the probe has probably entered an infinite loop.

If either one occurs, please submit an issue to the Solargraph repo.