Presently annotations have a message field. I assume there should not be an expectation that this field supports markdown/html/etc.
|
// A user-displayable message that explains the rule failure. |
|
// |
|
// Optional. |
|
string message = 2; |
The baked-in buf lint rules are relatively slim (they all fit on a page), so it hasn't been terribly annoying to look up that page to understand the rationale behind a rule. In contrast, I just wrote a buf lint plugin to interface with Google's api-linter googleapis/api-linter#1463 and that surfaces something like 100 rules. With so many rules, it's tedious to find the corresponding documentation page eg: https://linter.aip.dev/136/http-name-variable
The google linter has a mapping of rules to links, but it doesn't seem like there is an idiomatic way to expose them through buf. I am imagining a new field to provide these "read more" links, with a corresponding hyperlink ux similar to eslint's vscode extension:
Presently annotations have a
messagefield. I assume there should not be an expectation that this field supports markdown/html/etc.bufplugin/buf/plugin/check/v1/annotation.proto
Lines 41 to 44 in 29c6a58
The baked-in buf lint rules are relatively slim (they all fit on a page), so it hasn't been terribly annoying to look up that page to understand the rationale behind a rule. In contrast, I just wrote a buf lint plugin to interface with Google's api-linter googleapis/api-linter#1463 and that surfaces something like 100 rules. With so many rules, it's tedious to find the corresponding documentation page eg: https://linter.aip.dev/136/http-name-variable
The google linter has a mapping of rules to links, but it doesn't seem like there is an idiomatic way to expose them through buf. I am imagining a new field to provide these "read more" links, with a corresponding hyperlink ux similar to eslint's vscode extension: