Skip to content

Commit 78ae12a

Browse files
committed
docs(linter): add documentation for dependenttags
Adds documentation for the new `dependenttags` linter to `docs/linters.md`. This includes a description of the linter, its configuration options, and examples of how to use it.
1 parent 77262c4 commit 78ae12a

File tree

1 file changed

+38
-0
lines changed

1 file changed

+38
-0
lines changed

docs/linters.md

Lines changed: 38 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -6,6 +6,7 @@
66
- [ConflictingMarkers](#conflictingmarkers) - Detects mutually exclusive markers on the same field
77
- [DefaultOrRequired](#defaultorrequired) - Ensures fields marked as required do not have default values
88
- [DuplicateMarkers](#duplicatemarkers) - Checks for exact duplicates of markers
9+
- [DependentTags](#dependenttags) - Enforces dependencies between markers
910
- [ForbiddenMarkers](#forbiddenmarkers) - Checks that no forbidden markers are present on types/fields.
1011
- [Integers](#integers) - Validates usage of supported integer types
1112
- [JSONTags](#jsontags) - Ensures proper JSON tag formatting
@@ -92,6 +93,43 @@ If any of the 5 markers in the example above are missing, the linter will sugges
9293
When `usePatchStrategy` is set to `Ignore`, the linter will not suggest to add the `patchStrategy` and `patchMergeKey` tags to the `Conditions` field markers.
9394
When `usePatchStrategy` is set to `Forbid`, the linter will suggest to remove the `patchStrategy` and `patchMergeKey` tags from the `Conditions` field markers.
9495

96+
## DependentTags
97+
98+
The `dependenttags` linter enforces dependencies between markers. This prevents API inconsistencies where one marker requires the presence of another.
99+
100+
The linter is configured with a main tag and a list of required dependent tags. If the main tag is present on a field, the linter checks for the presence of the dependent tags based on the `type` field:
101+
- `All`: Ensures that **all** of the dependent tags are present.
102+
- `Any`: Ensures that **at least one** of the dependent tags is present.
103+
104+
### Configuration
105+
106+
```yaml
107+
lintersConfig:
108+
dependenttags:
109+
rules:
110+
- identifier: "k8s:unionMember"
111+
type: "All"
112+
dependents:
113+
- "k8s:optional"
114+
- identifier: "listType"
115+
type: "All"
116+
dependents:
117+
- "k8s:listType"
118+
- identifier: "example:any"
119+
type: "any"
120+
dependents:
121+
- "dep1"
122+
- "dep2"
123+
```
124+
125+
### Behavior
126+
127+
This linter only checks for the presence or absence of markers; it does not inspect or enforce specific values within those markers. Therefore:
128+
129+
- **Values:** The linter does not care about the values of the `identifier` or `dependent` markers. It only verifies if the markers themselves are present.
130+
- **Fixes:** This linter does not provide automatic fixes. It only reports violations.
131+
- **Same/Different Values:** Whether you want the same or different values between dependent markers is outside the scope of this linter. You would need other validation mechanisms (e.g., CEL validation) to enforce value-based dependencies.
132+
95133
## CommentStart
96134

97135
The `commentstart` linter checks that all comments in the API types start with the serialized form of the type they are commenting on.

0 commit comments

Comments
 (0)