Hi again @mislav, I made a pr yesterday, but I wasn't sure if the goal was to make column labels support color so I closed it.

Both pr's look similar, but I was wondering, to keep the code dry, would it be better to add a parameter to IssueLabelList that determines whether the label will be in a column or not?

This way the package shared still contains shared code and if a solution comes to light for colorized column labels, it would maybe be more seamless?

https://github.com/cli/cli/pull/4076/files

Just curious about your thoughts on it :)

Also a nil check can be added for cs there as well

This way the package shared still contains shared code and if a solution comes to light for colorized column labels, it would maybe be more seamless?

https://github.com/cli/cli/pull/4076/files

@bchadwic Ah, you should not have closed that PR! Your approach there looks good and solves all the issues that my PR aims to solve as well.

The reason I slightly prefer this PR (other than being obviously biased in favor of it) is that it splits the logic of rendering labels in issue list output and the rendering of issue view output into separate functions. Since those outputs are so different, I think that we benefit from the split. In the future, someone who edits logic in one of these commands will not inadvertently affect the logic in a different command.

Sure, these two label-rendering methods are now very similar, but I don't believe a little bit of duplication presents tech debt just yet. In fact, I would generally advise against trying to aggressively "dry" up pieces of code that look similar. If similar-looking code is used for different purposes (and commands issue list and issue view are definitely different purposes in my mind), then perhaps it should stay duplicated in the codebase.

@mislav thanks for sharing your insight!

I think that we benefit from the split. In the future, someone who edits logic in one of these commands will not inadvertently affect the logic in a different command.

I think this part drove you reasoning home for me. Dry seems like a good idea to me but I can see how in this scenario it may cause confusion later on. Thanks again 👍