Skip to content

Conversation

@phm07
Copy link
Contributor

@phm07 phm07 commented Jan 8, 2026

Closes #1295

@phm07 phm07 self-assigned this Jan 8, 2026
@phm07 phm07 requested a review from a team as a code owner January 8, 2026 11:24
@codecov
Copy link

codecov bot commented Jan 8, 2026

Codecov Report

❌ Patch coverage is 70.58824% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 72.49%. Comparing base (eeb8f68) to head (97b7e4d).
⚠️ Report is 3 commits behind head on main.

Files with missing lines Patch % Lines
internal/cmd/context/list.go 25.00% 1 Missing and 2 partials ⚠️
internal/cmd/base/list.go 33.33% 1 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1300      +/-   ##
==========================================
- Coverage   72.50%   72.49%   -0.01%     
==========================================
  Files         302      302              
  Lines       10995    11007      +12     
==========================================
+ Hits         7972     7980       +8     
- Misses       2150     2152       +2     
- Partials      873      875       +2     
Flag Coverage Δ
e2e 51.73% <29.41%> (+<0.01%) ⬆️
unit 67.48% <70.58%> (-0.01%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.


warnings, err := t.ValidateColumns(cols)
if err != nil {
return err
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This check was missing before. Since invalid columns were silently ignored before and now throw an error, this would be a breaking change. Do we want to keep it anyway?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I usually prefer not to maintain bug compatibility.

But in this case, maybe we can log a warning?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I can tell the validation for all list commands is already implemented and works, so no breaking change. I think this is the code path currently:

  • base.ListCmd#CobraCommand(): output.AddFlag(cmd, output.OptionNoHeader(), output.OptionColumns(outputColumns), output.OptionJSON(), output.OptionYAML())
  • output.AddFlag(): cmd.PreRunE = util.ChainRunE(cmd.PreRunE, validateOutputFlag(options))
  • output.validateOutputFlag() checks if all specified columns are valid

Maybe this is something to clean up in a follow-up PR, to remove one of the validations and only have a single way to validate the table and --output flag.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, it already implements validation. validateOutputFlag() runs before t.ValidateColumns(cols), so we could just ignore the error and only output the warnings.


// MarkFieldAsDeprecated marks the specified field as deprecated. The message will be printed
// to stderr if the column is used.
func (o *Table[T]) MarkFieldAsDeprecated(field string, message string) *Table[T] {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
func (o *Table[T]) MarkFieldAsDeprecated(field string, message string) *Table[T] {
func (o *Table[T]) MarkColumnAsDeprecated(column string, message string) *Table[T] {

I assume field means a cell in the context of the table, so we actually want to deprecate the column, and not the cell?

Copy link
Contributor Author

@phm07 phm07 Jan 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's consistent with the current naming. See this example:

// AddFieldFn adds a function which handles the output of the specified field.
func (o *Table[T]) AddFieldFn(field string, fn FieldFn[T]) *Table[T] {
	o.fieldMapping[field] = fn
	o.allowedFields[field] = true
	o.columns[field] = true
	return o
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think column is a better naming than field, but I'd like to keep it consistent to prevent confusion

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lets go with field now, and feel free to open a PR to rename it consistently to Column :)

@phm07 phm07 merged commit ecb5684 into main Jan 9, 2026
11 of 12 checks passed
@phm07 phm07 deleted the table-column-deprecation branch January 9, 2026 10:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

feat(table): mark columns as deprecated and show warning

4 participants