Skip to content

New Linter: Preferred Markers #139

@JoelSpeed

Description

@JoelSpeed

Over time, markers have evolved in at least two places, Kubernetes/Kubernetes, controller-tools (kubebuilder) and even within downstream projects.

As we move towards the upstream Kubernetes declarative validation project, I'm expecting that we will duplicate lots of the functionality of the kubebuilder markers (e.g. things like +kubebuilder:validation:MinLength).

In general, I believe that projects would like to be consistent, and, where they are using KAL, would likely want to enforce that certain markers are used over others.

We already have this today, there are three versions of optional (+k8s:optional, +kubebuilder:validation:Optional), and in would expect folks to prefer to have only one of these equivalent markers across their project.

So we should enable a configurable linter to allow folks to express that certain markers should be replaced with alternative, equivalent, preferred markers.

I could also see this being called DeprecatedMarkers or EquivalentMarkers, need some discussion on that.

I also think we should make sure that the configuration allows a potential future where we need to remap fields, so the config should be a structure that will allow this expansion in the future.

preferredmarkers:
  markers:
  - preferredIdentifier: some:marker
    equivalentIdentifiers:
    - some:old:marker
    - another:old:marker
    attrsMapping: # Future work if we find a need for it?
    - identifier: some:old:marker
       attrs:
       - source: oldAttr
         dest: newAttr

Metadata

Metadata

Assignees

Labels

kind/featureCategorizes issue or PR as related to a new feature.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions