Code struct for each kustomization field

[annasong20]

Status: This is a draft feature request. I will update it as I further my understanding of the codebase.

Is your feature request related to a problem? Please describe.
@KnVerey first suggested this change in #4590 (comment).

Essentially, every time kustomize looks for a specific behavior in its fields, each field requires its own processing code. For example, to find all files that a kustomization file references, kustomize localize would need code to look for referenced files within each field.

This approach is chunky: it makes the code more difficult to read. It's prone to bugs because not only is the logic is hard to follow, but also when the behavior of fields change, developers need to re-evaluate all various occurrences of code that processes the field in this manner.

Describe the solution you'd like
The problem is that, currently, the logic must be centrally managed because each field is not its own struct. If each field has its own struct type, the struct can implement different interfaces for the different use cases that need to process the field. In this way, most logic around processing the field will be local to each field, and thus easier to manage.

Describe alternatives you've considered
I have not come up with any alternatives at the moment.

Additional context
Will add as I go.

[k8s-ci-robot]

@annasong20: This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[KnVerey]

A bit of context to get you started: We actually already have structs (albeit not with the name you'd expect) representing the types that power most of these fields, and I didn't mean to suggest that we should have additional ones for the fields themselves. For example, the plugin struct here powers the NamespaceTransformer, i.e. the namespace: field. There are also already several interfaces associated with them: they must implement the Configurable interface in order to work as built-ins, and they must implement either the Generator interface or Transformer interface as applicable to be supported in the corresponding field.

This comes with a bunch of caveats though:

• This is tied to the implementation of built-ins as Go plugins, which is something we're theoretically reconsidering along with the Go plugin deprecation (it adds a lot of complexity). Develop new standard process for implementing builtin transformers #4400
• It's not true yet that all fields work this way, though we need them to for Composition: Convert resources and components to be backed by a reusable generator #4402
• Possibly, we could design something that could work with external transformers too, allowing them to tell us where these fields are. Related to Resolution of local file references in extensions transformer configuration #4154. Localize's use case is even more challenging though, since you don't want to run the transformers. Indeed, that makes option 3 on that issue the only one that is viable.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[annasong20]

Looking further at the code and discussions in #4797, I don't think this will be happening because

1. We don't need to. I opened this issue back when I didn't fully understand the codebase.
2. We seem hesitant to make larger changes to existing code.