Use diagnostic IDs for Language Server Packages #117
Assignees
Milestone
Comments
|
Not a bad idea IMO. |
|
@mkevenaar this makes sense to me! My only "concern" is regarding potential for growth. Do we think that 100 is "enough" for each type? Should we make it |
|
@gep13 fine by me, let's go with 3 digits. 1000 potential issues per type, ought to be enough for anybody! |
gep13
referenced
this issue
Feb 28, 2019
gep13
referenced
this issue
Feb 28, 2019
(doc) Minor change to numbering scheme - As documented here: https://github.com/gep13/chocolatey-vscode/issues/117#issue-414017887
|
This is now being implemented. I have been updating the issue here: https://github.com/gep13/chocolatey-vscode/issues/70 When the diagnostic code has been assigned to a rule. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Relates to #70
I have found that the
Diagnosticobject can contain aDiagnosticCodeobject. Containing an integer or string value.Looking at different other vscode packages they use something like [APPLICATION CODE][NUMBER] In our case that would be CHOCO####, so I think we could go down that road.
If we would go with the numbered version I think we should group them a bit.
I would suggest:
CHOCO0### for all Requirements
CHOCO1### for all Guidelines
CHOCO2### for all Suggestions
CHOCO3### for all Notes
Last three digits would be first come, first serve.
This way we can match these numbers client side and perhaps even use the "lightbulb" to have the user go to the package-validator wiki URL.
/cc: @gep13 @AdmiringWorm @steviecoaster
The text was updated successfully, but these errors were encountered: