Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added support for excluding search paths via globbing patterns #1161

Merged
merged 12 commits into from
Apr 24, 2018

Conversation

filipw
Copy link
Member

@filipw filipw commented Apr 12, 2018

This PR is intended to fix #896

It introduces a new omnisharp.json setting to control which paths OmniSharp should skip (paths can be explicit or use globbing patterns).
Globbing is provided via Microsoft.Extensions.FileSystemGlobbing which we conveniently already referenced 😄

By default the following set up is used:

{
  "fileOptions": {
    "excludeSearchPatterns": [
      "**/node_modules/**/*",
      "**/bin/**/*",
      "**/obj/**/*"
    ]
  }
}

So no files from bin, obj or node_modules are discovered, at any level.

The default setup can be overridden using a global or local omnisharp.json file.
For example:

{
  "fileOptions": {
    "excludeSearchPatterns": [
      "build/**/*",
      "**/TestFixtures/*.csproj"
    ]
  }
}

This should not find anything from a build folder relative to currently open OmniSharp and any csproj file directly inside TestFixtures.
The new service is used in place of the old SearchOption.AllDirectories scanning.

Copy link
Member

@david-driscoll david-driscoll left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems sensible to me, I had forgotten there was a globber from ms extensions.

{
public class FileOptions
{
public string[] ExcludeSearchPatterns { get; set; } = new[] { "**/node_modules/**/*", "**/bin/**/*", "**/obj/**/*" };
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we also add search inclusions? (in the future perhaps?

Kinda feels like it would be sort of similar to how we used to be able to do things with project.json.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about "**/.git/**/*"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that's a good one 👍

@david-driscoll
Copy link
Member

Going to merge tomorrow afternoon if there are no other objections

@filipw
Copy link
Member Author

filipw commented Apr 23, 2018

One thing that might improve the usability of this feature is perhaps we should split the exclusion patterns into 2 separate properties that you can override and customize.

The way inheritance rules in our hierarchical configuration work, is that you can override everything, but you completely negate the setup from the previous source.
What I mean is that at the moment if you want to to exclude i.e. /foo locally, you'd do this:

{
  "fileOptions": {
    "excludeSearchPatterns": [
      "foo/**/*"
    ]
  }
}

The problem is, this overrides the default setup and bin/obj/node_modules are no longer excluded anymore.
So to make it work in a way that the defaults are still observed, you'd have to technically carry over the defaults, like this:

{
  "fileOptions": {
    "excludeSearchPatterns": [
      "**/node_modules/**/*",
      "**/bin/**/*",
      "**/obj/**/*"
      "foo/**/*"
    ]
  }
}

This is not the greatest experience.
However, we could have 2 properties to control all this. Something like: userExcludeSearchPatterns and systemSearchPatterns. The default setup would be:

{
  "fileOptions": {
    "systemExcludeSearchPatterns": [
      "**/node_modules/**/*",
      "**/bin/**/*",
      "**/obj/**/*"
    ],
    "userExcludeSearchPatterns": []
  }
}

Then, you'd only override userExcludeSearchPatterns, and the systemExcludeSearchPatterns carry over automatically.

{
  "fileOptions": {
    "userExcludeSearchPatterns": [
      "foo/**/*"
    ]
  }
}

If this makes sense, I will push this change before we merge.

@david-driscoll
Copy link
Member

@filipw I like the idea of having a system level setting, and a user setting. 🚲 🏠 should the user property by userExcludeSearchPatterns or excludeSearchPatterns.

I tend to favor excludeSearchPatterns because most users won't want to even know that systemExcludeSearchPatterns exists, however by setting it up in such a way it makes the system exclusions less discoverable. I'm good to :shipit: either way.

@filipw
Copy link
Member Author

filipw commented Apr 24, 2018

OK thanks. So based on the convo, I added systemExcludeSearchPatterns and moved the "default" excludes there, and made the excludeSearchPatterns empty.

This way you can inject your own excludes into excludeSearchPatterns and still benefit from the systemExcludeSearchPatterns as at the end of the day, they get merged.
If anyone, for whatever reason, is eager to load projects from i.e. node_modules, systemExcludeSearchPatterns is also overridable.

@david-driscoll david-driscoll merged commit c53f211 into OmniSharp:master Apr 24, 2018
@DustinCampbell
Copy link
Contributor

@filipw: should we update the WIki page with this information? https://github.com/OmniSharp/omnisharp-roslyn/wiki/Configuration-Options

@filipw
Copy link
Member Author

filipw commented May 4, 2018

yes - you are right! I'll do that 📚

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Improve the "scan-all" behavior of all project systems
3 participants