You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/linters.md
+41-1Lines changed: 41 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -379,6 +379,35 @@ OpenAPI schema types map to Go types as follows:
379
379
- `array`: []T, [N]T (slices and arrays)
380
380
- `object`: struct, map[K]V
381
381
382
+
#### Strict Type Constraints
383
+
384
+
For markers with `AnyScope` and type constraints, the `strictTypeConstraint` flag controls where the marker should be declared when used with named types:
385
+
386
+
- When `strictTypeConstraint` is `false` (default): The marker can be declared on either the field or the type definition.
387
+
- When `strictTypeConstraint` is `true`: The marker must be declared on the type definition, not on fields using that type.
388
+
389
+
Example with `strictTypeConstraint: true`:
390
+
391
+
```go
392
+
// ✅ Valid: marker on type definition
393
+
// +kubebuilder:validation:Minimum=0
394
+
type Port int32
395
+
396
+
type Service struct {
397
+
Port Port `json:"port"`
398
+
}
399
+
400
+
// ❌ Invalid: marker on field using named type
401
+
type Port int32
402
+
403
+
type Service struct {
404
+
// +kubebuilder:validation:Minimum=0 // Error: should be on Port type definition
405
+
Port Port `json:"port"`
406
+
}
407
+
```
408
+
409
+
Most built-in kubebuilder validation markers use `strictTypeConstraint: true` to encourage consistent marker placement on type definitions.
410
+
382
411
### Default Marker Rules
383
412
384
413
The linter includes built-in rules for all standard kubebuilder markers and k8s declarative validation markers. Examples:
@@ -410,6 +439,7 @@ You can customize marker rules or add support for custom markers:
410
439
lintersConfig:
411
440
markerscope:
412
441
policy: Warn | SuggestFix # The policy for marker scope violations. Defaults to `Warn`.
442
+
allowDangerousTypes: false # Allow dangerous number types (float32, float64). Defaults to `false`.
413
443
markerRules:
414
444
# Override default rule for a built-in marker
415
445
"optional":
@@ -422,6 +452,7 @@ lintersConfig:
422
452
# Add a custom marker with scope and type constraints
423
453
"mycompany:validation:NumericLimit":
424
454
scope: any
455
+
strictTypeConstraint: true # Require declaration on type definition for named types
425
456
typeConstraint:
426
457
allowedSchemaTypes:
427
458
- integer
@@ -446,13 +477,22 @@ lintersConfig:
446
477
**Type constraint fields:**
447
478
- `allowedSchemaTypes`: List of allowed OpenAPI schema types (`integer`, `number`, `string`, `boolean`, `array`, `object`)
448
479
- `elementConstraint`: Nested constraint for array element types (only valid when `allowedSchemaTypes` includes `array`)
480
+
- `strictTypeConstraint`: When `true`, markers with `AnyScope` and type constraints applied to fields using named types must be declared on the type definition instead of the field. Defaults to `false`.
449
481
450
482
If a marker is not in `markerRules` and not in the default rules, no validation is performed for that marker.
451
483
If a marker is in both `markerRules` and the default rules, your configuration takes precedence.
452
484
453
485
### Fixes
454
486
455
-
The `markerscope` linter does not currently provide automatic fixes. It reports violations as warnings or errors based on the configured policy.
487
+
When the `policy` is set to `SuggestFix`, the `markerscope` linter provides automatic fix suggestions for marker violations:
488
+
489
+
1. **Scope violations**: For markers applied to the wrong scope (field vs type), the linter suggests moving the marker to the correct location.
490
+
491
+
2. **Type constraint violations**: For markers applied to incompatible types, the linter suggests removing the invalid marker.
492
+
493
+
3. **Named type violations**: For AnyScope markers with type constraints applied to fields using named types, the linter suggests moving the marker to the type definition if the underlying type is compatible with the marker's type constraints.
494
+
495
+
When the `policy` is set to `Warn`, violations are reported as warnings without suggesting fixes.
456
496
457
497
**Note**: This linter is not enabled by default and must be explicitly enabled in the configuration.
0 commit comments