Skip to content
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

Merged
merged 32 commits into from Mar 26, 2019

Conversation

natealcedo
Copy link
Contributor

@natealcedo natealcedo commented Mar 3, 2019

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!

image

@@ -223,6 +224,25 @@ type NotifyMode =
| 'success-change'
| 'failure-change';

type DisplayNameColor =
Copy link
Member

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

Copy link
Contributor Author

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 😄

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'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

Copy link
Contributor Author

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

@@ -313,7 +333,8 @@ export type ProjectConfig = {
dependencyExtractor?: string;
detectLeaks: boolean;
detectOpenHandles: boolean;
displayName: string | null | undefined;
displayName?: string;
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

@SimenB
Copy link
Member

SimenB commented Mar 3, 2019

I like the idea!

/cc @thymikee @rogeliog @jeysal

@jeysal
Copy link
Contributor

jeysal commented Mar 3, 2019

I also love the idea! We could also consider doing this automagically without configuration changes, which is what Lerna does.

@SimenB
Copy link
Member

SimenB commented Mar 3, 2019

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

@thymikee
Copy link
Collaborator

thymikee commented Mar 3, 2019

I'm a fan of what @SimenB says (API- and UI-wise)

@jeysal
Copy link
Contributor

jeysal commented Mar 3, 2019

Fine with configuration overrides too.
For the defaults we could hash and modulo the displayName || name to pick something from a set of colors consistently, not based on ordering.
Or try to be smart and look at runner to pick a consistent color for jest-runner-tsc, jest-runner-eslint, etc.?

@natealcedo
Copy link
Contributor Author

I agree with @SimenB. I'd like to have a sane set of defaults but yet allows developers to override.

@thymikee
Copy link
Collaborator

ping @natealcedo :)

@natealcedo
Copy link
Contributor Author

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?

@SimenB
Copy link
Member

SimenB commented Mar 19, 2019

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

@jeysal
Copy link
Contributor

jeysal commented Mar 19, 2019

The default color should be stable though, so jest-runner-asdfghjkl should get the same color by default every time.

@natealcedo
Copy link
Contributor Author

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.

@jeysal
Copy link
Contributor

jeysal commented Mar 19, 2019

If you've got 5 packages with jest-runner, jest-runner-eslint, and jest-runner-tsc each, having your 15 Jest projects grouped into blue tests, red lints, green typechecks or whatever would be nice IMO

@natealcedo
Copy link
Contributor Author

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.

@jeysal
Copy link
Contributor

jeysal commented Mar 19, 2019

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.

@natealcedo
Copy link
Contributor Author

@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 displayNameColor or displayName object as per what @SimenB has suggested in projectConfiguration. What you're suggesting entails reading the runner option in a project configuration and if it's not the default jest-runner AND displayNameColor is not set, we set default colors for the runner based on the output of hashing and modulo-ing the runner from a list of colors in a color wheel. Is that correct?

@rogeliog
Copy link
Contributor

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).

@rogeliog
Copy link
Contributor

rogeliog commented Mar 19, 2019

What if we start by adding the color as an opt-in feature, and then continue the “smart default” discussion post merge?

@natealcedo
Copy link
Contributor Author

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.

@jeysal
Copy link
Contributor

jeysal commented Mar 19, 2019

I'd be fine with starting out as a strictly opt-in feature, of course.

What you're suggesting entails reading the runner option in a project configuration and if it's not the default jest-runner AND displayNameColor is not set, we set default colors for the runner based on the output of hashing and modulo-ing the runner from a list of colors in a color wheel. Is that correct?

Yes, essentially (minus the "if it's not the default jest-runner", don't see why that would matter)

@natealcedo
Copy link
Contributor Author

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.

@natealcedo
Copy link
Contributor Author

natealcedo commented Mar 25, 2019

Just pushed in a couple of updates and added tests. You guys think this needs an integration test or is testing printDisplayName good enough? What else does this PR need besides updating the CHANGELOG? I'm guessing since this a feature, some docs are going to need an update. Could someone point me in the right direction? :)

@SimenB
Copy link
Member

SimenB commented Mar 26, 2019

Just pushed in a couple of updates and added tests. You guys think this needs an integration test or is testing printDisplayName good enough?

An integration test for displayName in general would be nice. We also replace colors in the snapshots, so you'll get nice <red>name</> in the snapshots

I'm guessing since this a feature, some docs are going to need an update. Could someone point me in the right direction? :)

Doesn't seem like displayName is documented - it should be. Mind adding it (to Configuration.md)? In docs/ it should match the logic as of this PR, while in website/versioned_docs it should match the behavior (single string only) currently published

@natealcedo
Copy link
Contributor Author

natealcedo commented Mar 26, 2019

An integration test for displayName in general would be nice. We also replace colors in the snapshots, so you'll get nice name</> in the snapshots

Will do so. I'll just update the projects configuration integration test and chuck in a displayName with a color

Doesn't seem like displayName is documented

I found this. Though it's just a small hint about it https://jestjs.io/docs/en/configuration#projects-array-string-projectconfig

@SimenB
Copy link
Member

SimenB commented Mar 26, 2019

I found this. Though it's just a small hint about it 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)

@natealcedo
Copy link
Contributor Author

natealcedo commented Mar 26, 2019

Hey, I'm facing an issue with integration testing.
https://github.com/facebook/jest/blob/master/e2e/runJest.ts#L74
We don't allow colors in integration testing.

I've tried adding in an option to force color in runJest. Even then, the snapshot isn't accurate.

image

The colors you see at the top is me printing stderr,
The actual snapshot is like this


exports[`displayName should print out colors 1`] = `
"</><inverse><bold><green> PASS </></></></> </><inverse> SERVER </></></> <dim>backend/</><bold>a.test.js</>
</><inverse><bold><green> PASS </></></></> </><inverse> CLIENT </></></> <dim>client/</><bold>b.test.js</>

<bold>Test Suites: </><bold><green>2 passed</></>, 2 total
<bold>Tests:       </><bold><green>2 passed</></>, 2 total
<bold>Snapshots:   </>0 total
<bold>Time:</>        <<REPLACED>>
<dim>Ran all test suites</><dim> in </>2<dim> projects</><dim>.</>"
`;

@natealcedo natealcedo changed the title [WIP] Add color to displayName in project configuration. dd color to displayName in project configuration. Mar 26, 2019
@natealcedo natealcedo changed the title dd color to displayName in project configuration. Add color to displayName in project configuration. Mar 26, 2019
@natealcedo
Copy link
Contributor Author

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.

Copy link
Member

@SimenB SimenB left a 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]
Copy link
Member

Choose a reason for hiding this comment

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

just string

@natealcedo
Copy link
Contributor Author

One last set of changes to just add a new line and a colon for validation error in normalize.

image

@github-actions
Copy link

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.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 11, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants