-
Notifications
You must be signed in to change notification settings - Fork 12
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
(GH-121) Implement ConfigurationHandler #135
Conversation
@tintoy @mholo65 would either of you be able to have a review of this PR? Thanks! |
This allows for configuration similar to the following:
NOTE: None of this is fixed in stone, just to show how things can be done. |
{ | ||
try | ||
{ | ||
return (Task<Unit>)OnDidChangeConfiguration(request); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At first glance, I'm wondering whether this cast will ever succeed? OnDidChangeConfiguration
returns Task.CompletedTask
, not Task<Unit>
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tintoy Ah, that one... I think I did that just to get it to compile 😄 This will likely need some tidy up.
So far it looks good to me |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks amazing!
- Based on the work in this repository: https://github.com/tintoy/msbuild-project-tools-server - Needed updated due to changes in most recent version of Omnisharp
- Added new interface to provide up to date Configuration - Changed Rule registrations. Use container, rather than reflection - This will mean that each rule has to be registered with container
- Grouping all files into correct folders - Changing namespaces, etc
- Handle the case where there is no element - Diagnostics are placed at top of file
@AdmiringWorm @mkevenaar @tintoy I have done a fair bit of refactoring here, but I think it is all for the greater good.
What are your collective thoughts on these changes? |
Looks good to me - getting everything from the DI container will keep things simpler :) |
@gep13 do you have some code for the above? |
@mholo65 I have it locally, but I was struggling to get things working the way I want it to. I am thinking about splitting that work into a separate PR. |
Have you looked how https://github.com/DavidAnson/vscode-markdownlint did it? It has a MIT license Also I think the CHOCO0### should not be ignorable, as they are a requirement. |
Yes. I have been using that repository, as well as this one https://github.com/Jason-Rev/vscode-spell-checker, as a reference for what I am trying to achieve.
I have had the same thought. While it is correct to say that this is a requirement for pushing to Chocolatey.org, it may not be a requirement when pushing packages internally. As such, I think I am going to leave the ability to suppress a requirement, but also put in another configuration parameter named something like |
@@ -39,6 +45,15 @@ static void ConfigureServices(IServiceCollection services) | |||
{ | |||
services.AddSingleton<BufferManager>(); | |||
services.AddSingleton<DiagnosticsHandler>(); | |||
services.AddSingleton<Configuration>(); | |||
services.AddSingleton<INuspecRule, CopyrightAndAuthorFieldShouldntContainEmailRequirement>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm all for having the services registered and using with dependency inject,
but wouldn't it be better to have each type registered dynamically instead of having to add them every time a rule gets added.
Something like:
var typeLocator = new TypeLocator();
foreach (var nuspecRule in typeLocator.GetTypesThatInheritOrImplement<INuSpecRule>())
{
services.AddSingleton(typeof(INuSpecRule), nuspecRule);
}
I know you deleted the TypeLocater, but I still think it could be useful to have.
I think that makes sense, and I'm all for it.
Perhaps adding the validation type as a property could also be useful?
👍 |
- This will be a breaking change - Allows for future expansion, and better grouping of related properties - Removed mention of MSBuild
- To help with the registration of all validation rules
- So that it is easy to identify rule types
@AdmiringWorm @mkevenaar I have implemented the suggestions that were left in this PR, and I have opened up some follow up issues here: https://github.com/gep13/chocolatey-vscode/issues/140 I am going to go ahead and merge this in, as it impacts on a lot of different sections, and I don't want to hold up any further work. I have tested most of the changes, and it seems to be working fine. If there are any issues found, we can correct them as we go. As I mention in the related issue, this will be a breaking change, as I had to refactor the default configuration that is contributed by the extension. Let me know if you have any questions about anything. |
@all-contributors please add @tintoy for ideas, review |
I've put up a pull request to add @tintoy! 🎉 |
To allow for suppressing individual rules.
Relates to #121