-
Notifications
You must be signed in to change notification settings - Fork 234
feat: migrate to color.attachment from @heroku/heroku-cli-util #3471
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: v11.0.0
Are you sure you want to change the base?
Conversation
This PR migrates add-on attachment name coloring from generic cyan/green colors to the semantic color.attachment() function. This is part 4 of 17 of the color system migration plan. Changes: - Updated imports from @heroku-cli/color to @heroku/heroku-cli-util - Replaced color.cyan() and color.green() with color.attachment() for attachment names - Also updated addon references to use color.addon()
k80bowman
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks mostly good, just a couple of small questions.
| @@ -1,28 +1,31 @@ | |||
| import {color} from '@heroku-cli/color' | |||
| /* eslint-disable perfectionist/sort-objects */ | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why disable this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
disabling this because i kept trying to "fix" it. but we actually want the non-alphabetical order for displaying addon info on line 36. styledObject actually pays attention to the "order" of the keys. we should probably change the interface to styledObject to explicitly declare the output order in some other way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add an eslint-disable-next-line on the line above the styledObject call then so it's more clear why you're disabling it? Rather than disabling it for the entire file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for pushing me on this. i actually didn't think you could do something like that with eslint, but i learned that you can, although slightly differently than you describe. you do:
/* eslint-disable perfectionist/sort-objects */
...some code block...
/* eslint-enable perfectionist/sort-objects */0f16b48 to
e51ca3e
Compare
sbosio
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple things that I think need to be corrected before merging.
| return formatPrice({hourly: true, price: addon.plan?.price}) | ||
| } | ||
|
|
||
| return color.dim(printf('(billed to %s app)', newColor.app(addon.app?.name || ''))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case, cyan was used to differentiate the owning app (purple) from other apps (cyan). That differentiation is now lost. You can compare the outputs of both commands:
Moreover, cyan being used for attachment names makes this more confusing. IMHO it's not good to rely on coloring to only differentiate stuff (because of accessibility).
My suggestions:
- Keep all app names with same colorization (keep the current changes). Remove the cyan on
appsat the end of the last phrase after the table, then use the correct attachment color forattachmentsword on that very same sentence.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, i think consistency is the primary goal. like, color should tell you what the thing is. inconsistently coloring really diminishes the benefit of the "oh that has a purple hexagon, must be an app" effect. there are some caveats here. for instance, when you're renaming an app and we display the name of the thing that isn't yet an app (but will be).
i think we can do better than arbitrarily coloring things just to distinguish between individual items. we should be able to show that in other ways (and we really should, for reasons you described).
i agree, cyan being used for attachment names is just a miss. i'll correct it.
the last message using a bunch of colors is interesting. i dunno how i feel about it. we tend to just use colors to denote the names of things, not words that generally describe them. i'll probably remove all the coloring from that message. i think if we tried to be consistent with that across the cli it'd be color overload.
| overflow: 'wrap', | ||
| }, | ||
| ) | ||
| ux.stdout(`The table above shows ${color.magenta('add-ons')} and the ${color.green('attachments')} to the current app (${newColor.app(app)}) or other ${color.cyan('apps')}.\n `) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is where I suggest changing to:
| ux.stdout(`The table above shows ${newColor.addon('add-ons')} and the ${newColor.attachment('attachments')} to the current app (${newColor.app(app)}) or other apps.\n`) |
| .join(', ') | ||
|
|
||
| warnings.push(`This command will affect the app${(attachments.length > 1) ? 's' : ''} ${uniqueAttachments}.`) | ||
| warnings.push(`This command will affect the app${(attachments.length > 1) ? 's' : ''} ${color.attachment(uniqueAttachments)}.`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to be reverted and fixed.
The name uniqueAttachments is misleading. Should've been named uniqueAppNames, because through the list of attachments it composes a set of unique app names associated with the attachments. See the previous three lines. It's a list of unique app names with the correct color (for apps) already applied.
But the pluralization is wrong, because it check attachments' length when it should be checking uniqueAttachments length.
At a glance:
| warnings.push(`This command will affect the app${(attachments.length > 1) ? 's' : ''} ${color.attachment(uniqueAttachments)}.`) | |
| warnings.push(`This command will affect the app${(uniqueAttachments.length > 1) ? 's' : ''} ${uniqueAttachments}.`) |
It's up to you if you want to rename the variable to something like uniqueAppNames to make it semantically correct, 😄 .
Summary
This PR migrates add-on attachment name coloring from generic
color.cyan()andcolor.green()to the semanticcolor.attachment()function from@heroku/heroku-cli-util. This is part 4 of 17 of the color system migration plan.Changes:
@heroku-cli/colorto@heroku/heroku-cli-utilin 5 filescolor.cyan()andcolor.green()withcolor.attachment()for attachment namescolor.addon()where applicableFiles modified:
commands/addons/attach.tscommands/addons/detach.tscommands/addons/index.tscommands/addons/info.tscommands/pg/connection-pooling/attach.tsType of Change
Breaking Changes (major semver update)
!after your change type to denote a change that breaks current behaviorFeature Additions (minor semver update)
Patch Updates (patch semver update)
Testing
Steps:
heroku addons:attach,heroku addons:detach, orheroku addons:infoto verify attachment names display with the new semantic coloringRelated Issues
Part of the color system migration plan (4 of 17).