Command "fmt" is deprecated - Declare a formatting transformer in your kustomization instead

[whyvez]

When using kustomize cfg fmt I got this warning.

Command "fmt" is deprecated, imperative formatting will no longer be available in kustomize v5.
Declare a formatting transformer in your kustomization instead.

I don't understand the suggestion, "Declare a formatting transformer in your kustomization instead.".

Can someone explain what this means?

[natasha41575]

Apologies for the cryptic and confusing warning. We have decided that commands such as kustomize cfg fmt are out of scope for builtin kustomize and would encourage you to instead create a plugin transformer to format your resources instead. You can follow the guides here: https://kubectl.docs.kubernetes.io/guides/extending_kustomize/ to create a plugin transformer, add the formatting transformer to the transformers field of your kustomization file, and run kustomize build to invoke it.

We would appreciate feedback if either:

• It is difficult to create your own extension for kustomize to format your resources
• This feature is popular enough for us to create a formatting transformer under an official CNCF plugin repo.

Please comment back if you have any further questions!

/kind support
/triage accepted

[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

[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:

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

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

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

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:

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

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

/close

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.

[greenkiwi]

@natasha41575 we just ran across this issue and were wondering whether there were any good examples to follow. We have attempted to have all of our "code" use strong formatting. Google-java-formatter for java, black for python, etc. This has improved our code review as there are fewer style discussions and users are less likely to miss or change large chunks of code. For k8s objects, having a standard order makes looking at and reviewing diffs much easier.

We don't really want to build our whole system around a feature that will be removed in kustomize v5, but the alternative seems to be pretty heavy-handed. Needing to add a new formatter argument to every kustomization.yaml file. It also seems a bit strange for users to run kustomize build to have their source formatted.

Cheer,
Adam

[matthewhembree]

I agree that kustomize build is the wrong place to do formatting. I don't think formatting should be in-band. I can't think of a programming language that does formatting that way.

[goutkannan]

I agree with the last 2 comments, I wrote a couple of go/exec plugins and they go deprecated in favor of KRM plugins. KRM plugins are still in the Alpha stage, I am worried that those types of plugins would be temporary too.