ionide / ionide/FSharp.Analyzers.SDK

Proposal: More flexible Analyzer probing rules

Open
#32 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
F#
Stars
85
Forks
28
Avg merge
1d 8h
Merged PRs (30d)
20

Description

I propose that we change the current Analyzer discovery mechanism to be more like the probing rules for type providers, in an effort to aid discoverability and usability of analzyers.

Currently, the analzyer probing logic is described as:

* from a given directory
* look in that directory and all subdirectories
* for any dlls named *Analyzer*.dll

This is brittle for a few reasons:

* it requires the analyzer assemblies to live at a common subdirectory (which often leads folks to use paket, which we may not want to force)
* it can load an analyzer incorrectly if the analyzer has multiple dlls for different target framework monikers
* it can miss analyzers if the author didn't name them correctly

**Describe the solution you'd like**

I propose that we adopt a directory structure similar to that of type providers, something like (assuming a package root of `/`)

```
/analyzers/
/analyzers/runtime/-
```

For a complete example see the nuget package documentation [here](https://docs.microsoft.com/en-us/nuget/create-packages/supporting-multiple-target-frameworks#framework-version-folder-structure).

The idea would be to mimic that logic, underneath a directory that specifically opts the package into analyzers.

Assuming this, the logic for discovering analyzers in tooling would be

* from the set of referenced packages in a project
* filter down to those that contain `analyzers`
* filter down to the correct TFM directories for the tool being run and load the dlls from those directories
* from the assemblies loaded, probe for members of type Analyzer or equivalent as we do today

**Describe alternatives you've considered**
An alternative would be to not do this and attempt to probe all of project dependencies, not just loading dlls from a folder. I disagree with this approach due to the immense amount of probing work that would be done, especially given the current logic of just taking every dll from every subfolder of the probed folder root.

**Additional context**
Add any other context or screenshots about the feature request here.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.