-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
Add color to displayName in project configuration. #8025
Add color to displayName in project configuration. #8025
Conversation
@@ -223,6 +224,25 @@ type NotifyMode = | |||
| 'success-change' | |||
| 'failure-change'; | |||
|
|||
type DisplayNameColor = |
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.
Would be good to extract these from chalk
instead of hard coding them
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.
Oh I was hard coding this because of what I mentioned about not being sure if we should curate the colors that we should allow or if we should allow everything. Hence the early PR 😄
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.
I've taken a look at the types provided by chalk and they don't expose the colors. https://github.com/chalk/chalk/blob/master/index.d.ts#L231
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.
Just as an FYI, opened up this PR. Hopefully this gets merged and we won't have to hardcode colors here. chalk/chalk#336
packages/jest-types/src/Config.ts
Outdated
@@ -313,7 +333,8 @@ export type ProjectConfig = { | |||
dependencyExtractor?: string; | |||
detectLeaks: boolean; | |||
detectOpenHandles: boolean; | |||
displayName: string | null | undefined; | |||
displayName?: string; |
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.
I wonder if we should do displayName?: string | {name: string; color: DisplayNameColor}
instead of adding a new option?
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.
Oh, I like this implementation better actually.
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.
I like the API that @SimenB is suggesting.
I also love the idea! We could also consider doing this automagically without configuration changes, which is what Lerna does. |
I think I'd like to keep colors consistent. Or maybe I get used to lint being magenta, tests being green (of course) and compiling being yellow? It'd be nice to not rely on ordering. If colors are not specified though, I'm definitely in favor of assigning different colors to each automatically |
I'm a fan of what @SimenB says (API- and UI-wise) |
Fine with configuration overrides too. |
I agree with @SimenB. I'd like to have a sane set of defaults but yet allows developers to override. |
ping @natealcedo :) |
Oh hey sorry I haven't had the chance to take a look at this again. It doesn't seem like there was a conclusion to the discussion above though. To get this PR moving forward, should I start taking a look at what runners we have and think about what colors to assign them as a default? Thoughts @jeysal @SimenB? |
I don't think jest should set a default for runners, I just meant that I as a user should be able to set colors so it's consistent in a project |
The default color should be stable though, so |
So going by what @SimenB says, let's just keep the default color to white then and if a consumer provides an override in his project configuration, we choose what the consumer wants? I've given it some thought and I've come to the conclusion that I don't quite like having jest predetermine colors for runners. Seems like we're overthinking it IMO by going down the path of implementing a color wheel. |
If you've got 5 packages with |
That's a point but doesn't jest NOT group the output by runner? I'm maybe wrong here but I'm just speaking from the top of my head. |
What do you mean by grouped? I'm referring to the colors as a means of grouping, even though the individual output lines may be interspersed. |
@jeysal Ah yes, I was confused about what you said initially. It seems like we're on the same page then. To carry on the discussion, it seems now that we're going about this slightly different. The purpose of this PR is to enable users to change the color output of a project by way of adding in a |
I guess that most repos that use projects and displayNames, don’t use custom runners, but rather multiple jest configurations depending on how their repo is structured.(for example, server vs client). |
What if we start by adding the color as an opt-in feature, and then continue the “smart default” discussion post merge? |
Sure thing. That sounds like a reasonable compromise to get this feature moving. I don't have the bandwidth currently but let me take a look at it over the weekend. |
I'd be fine with starting out as a strictly opt-in feature, of course.
Yes, essentially (minus the "if it's not the default jest-runner", don't see why that would matter) |
Oh I was thinking that way because we’d want to keep the default behaviour as is if it’s the default runner. But then I realised that it wouldn’t matter since the implementation ideally should do the same thing. |
Just pushed in a couple of updates and added tests. You guys think this needs an integration test or is testing |
An integration test for
Doesn't seem like |
Will do so. I'll just update the projects configuration integration test and chuck in a displayName with a color
I found this. Though it's just a small hint about it https://jestjs.io/docs/en/configuration#projects-array-string-projectconfig |
Yeah, it should have its own section (even though it's essentially just useful if you have multiple projects) |
Hey, I'm facing an issue with integration testing. I've tried adding in an option to force color in The colors you see at the top is me printing stderr,
|
I've updated the docs and the changelog. I think this should be in a good enough shape to receive a full review. I'm opting not to add an integration test due to difficulties getting snapshots to work with it since runJest doesn't support colors and I've added in unit tests for the changes. |
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 is awesome, thanks!
@@ -289,6 +289,12 @@ The `extract` function should return an iterable (`Array`, `Set`, etc.) with the | |||
|
|||
That module can also contain a `getCacheKey` function to generate a cache key to determine if the logic has changed and any cached artifacts relying on it should be discarded. | |||
|
|||
### `displayName` [string, object] |
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.
just string
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Summary
The displayName configuration under project configuration is a cool feature. One thing I have an issue with it is that it's not immediately apparent which project a test is from without reading the displayName. Adding an option to colorize this field makes it visually apparent and I think that it's a nice to have.
Hence, I'm just opening up this PR to get feedback on this feature if you guys think it's something that's worth adding. Since we use
chalk
underneath to do the coloring, I thought why not just open up the whole suite of colors for developers to choose. I'd like to highlight that some developers are already asking for colors in jest diff as in #7980 so I'm sure someone will ask for this. If not, I myself would like this feature.If you guys like think this is worth adding, it would be good to have a discussion on whether or not to limit which colors we should allow. Here's a screenshot of me having two projects and setting their colors to blue and magenta.
Cheers!