Provide Chocolatey Language Server support #70
Comments
- This still needs some work, but it is at least working now - Single rule for templated values has been implemented - Question remains over how to get server into file system - Question remains over sending entire file to server
|
@mkevenaar @steviecoaster @AdmiringWorm if any of you are interested in helping with the validator rules within the VSCode extension, I have now checked in a working sample of the templated variables being highlighted as errors. In order to get this to work on your machine, you will have to do the following:
|
gep13
changed the title
|
@mkevenaar @steviecoaster @AdmiringWorm I have updated the original comment with the initial set of rules that I think should be applied. I would suggest, assuming that you are interested in helping, that we take 1 rule at a time. i.e. 1 rule per PR. |
|
@gep13 do you want to implement the rules from chocolatey/package-validator#184 also? |
|
@mholo65 I have added the initial implementation of this into the Chocolatey VSCode Extension. I haven't included the schema validation just yet, as there is a question over where exactly that schema is going to reside, so leaving that out for now, but I will add it in once everything is in place. Thanks again for all your help on getting this started! |
Yes, that makes sense. If you can list all the ones that "will" be included, I will get them added to the list above |
|
@gep13 done: I have removed the checklist. |
|
@gep13 great work! As for the Schema, I’d recommend that you use an unique namespace instead of the NuGet’s NuSpec namespace. If I understood correctly, you have a couple of additional elements that’s not available in the NuGet NuSpec. |
|
DiagnosticSeverity.Error:
DiagnosticSeverity.Hint: (Notice the little three dots)
DiagnosticSeverity.Information:
DiagnosticSeverity.Warning:
|
|
Based on the above, I think the mapping between the rule types should be the following: DiagnosticSeverity.Error -> Requirement Thoughts? @mkevenaar @steviecoaster @AdmiringWorm |
That is exactly the question that I was referring to 😄 |
(GH-70) Validation for description element in nuspec file
- That way, all validations can be loaded at once - Based on conversation in GitHub issue
|
@AdmiringWorm @mkevenaar I have taken a stab at refactoring the code to use a similar system to package validator. Now, all rules will be loaded based on whether they come from |
- Added UrlValidValidation rules for all Url elements. - Added generic url_is_valid function
- Switch to using an extension method - Corrected whitespace
|
To make sure that @AdmiringWorm, @steviecoaster, @gep13 and I are not working on the same rule, @gep13 suggested to update the issue; So here goes: I am going to work on:
|
* pr101: (GH-70) Added validation if URL is SSL capable.
(GH-70) Implemented rule to check if licenseUrl is set when requireLicenseAcceptance is true
(GH-70) Implemented validation rule to check if a package id ends with .config
(GH-70) Implemented validation rule to check if package id contains pre-release tags
(GH-70) Implemented rule to check if a project url have been specified
(GH-70) Implemented rule to check if tags contains a comma
(GH-70) Implemented validation for tags being supplied
|
hmm, been thinking of the encoding check guideline. EDIT: Seems like there is, I completely missed that. |
|
I'll be looking into creating a rule for the missing suggestion (The one about icon url being svg or png). |
|
@mkevenaar I just pushed the note rule I had been working on. I used the rule code |
(GH-70) Implemented validation rule to check if icon url is svg or png
(GH-70) Implemented validation for id with underscore rule
…chMaintainerNote (GH-70) Validates that the author does not match the maintainer
…into develop * 'develop' of https://github.com/gep13/chocolatey-vscode: (181 commits) Bump @types/node-fetch from 2.3.0 to 2.3.4 Bump @types/node from 11.12.0 to 12.0.2 Bump expect from 24.7.1 to 24.8.0 Bump typescript from 3.3.4000 to 3.4.5 Bump mocha from 6.0.2 to 6.1.4 Bump vscode from 1.1.30 to 1.1.34 Bump tslint from 5.14.0 to 5.16.0 Bump @types/xml2js from 0.4.3 to 0.4.4 Bump expect from 24.5.0 to 24.7.1 Bump @types/node-fetch from 2.1.7 to 2.3.0 Bump @types/node from 11.11.6 to 11.12.0 Bump @types/node from 11.11.5 to 11.11.6 Bump @types/node from 11.11.4 to 11.11.5 Bump @types/node-fetch from 2.1.6 to 2.1.7 Bump @types/node from 11.11.3 to 11.11.4 Bump typescript from 3.3.3333 to 3.3.4000 (GH-70) Validates that the author does not match the maintainer Bump @types/node from 11.11.1 to 11.11.3 Bump tslint from 5.13.1 to 5.14.0 (doc) Added priority to new docs ...
Simply put, this isn't ready for usage, and lots of decisions need to be made about how it will be used going forward. Rather than prevent other releases of this extension while we are waiting on the Language Server support, let's move the current code into a branch and continue over there.
This code has been taken from the develop branch, so that we can continue the development of the language server portion of the extension without preventing other ongoing work from going out the door. We will get to this at some point, but for now, this should be regarded as a nice have.
Rules that should be implemented:
Requirements
Also, rules added as part of PR 184:
Guidelines
Suggestions
Notes
The text was updated successfully, but these errors were encountered: