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 displayName to MPR #4327

Merged
merged 10 commits into from
Aug 27, 2017
Merged

Add displayName to MPR #4327

merged 10 commits into from
Aug 27, 2017

Conversation

rogeliog
Copy link
Contributor

Summary

Fixes #4065

Adds the displayName option for multi project runner

Pending items

  • Add docs for displayName

Test plan

I have some questions regarding the UX for this:

  1. What happens when some of the projects have displayName and some don't do we simply show the name for some and leave it empty for the rest? Or does displayName need to be present in either all or none of the projects?
    screen shot 2017-08-22 at 3 24 30 pm

  2. What happens when the displayName of the project is really long, or not all caps, or with spaces? Do we normalize the diplayName to all caps no spaces?
    screen shot 2017-08-22 at 3 24 57 pm

  3. Do we allow non alpha numeric characters like emojis?
    screen shot 2017-08-22 at 3 35 58 pm

Copy link
Contributor

@aaronabramov aaronabramov 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 a game changer!
a few nits

"
`;

exports[`can pass projects or global config 5`] = `
"PASS project1/__tests__/file1.test.js
"PASS BACKEND project1/__tests__/file1.test.js
PASS UI project3/__tests__/file1.test.js
Copy link
Contributor

Choose a reason for hiding this comment

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

this is probably going to fail when they're executed in different order. Previous test had identical lines (:

Copy link
Member

Choose a reason for hiding this comment

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

Ohh, now I get this change that @thymikee was making for snapshots. Can we merge that one for the next alpha release? We can break the snapshot format for 21, and update the snapshot version. What do you think?

Copy link
Contributor

Choose a reason for hiding this comment

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

yeah! i'll rerecord snapshots in www

Copy link
Contributor

Choose a reason for hiding this comment

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

do we have a mechanism to have multiple versions of snapshots at the same time? i remember we had this idea somewhere

Copy link
Contributor

Choose a reason for hiding this comment

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

we should be able to decouple snapshot format changes from jest as a framework changes.
If jest update doesn't go well, rolling it back creates a huge mess in master because of all snapshot conflicts

Copy link
Member

Choose a reason for hiding this comment

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

This is not the right place to have this conversation, I commented here: #4183 (comment) cc @thymikee

Copy link
Contributor Author

@rogeliog rogeliog Aug 22, 2017

Choose a reason for hiding this comment

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

types/Config.js Outdated
@@ -15,7 +15,7 @@ export type HasteConfig = {|
defaultPlatform?: ?string,
hasteImplModulePath?: string,
platforms?: Array<string>,
providesModuleNodeModules: Array<string>,
providesModuleNodeModules: Array<string>
Copy link
Contributor

Choose a reason for hiding this comment

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

what happened to the formatting?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I was about to add that comment... this is what my Prettier config is formatting this file to... I'll double check if I have something wrong on my setup

`${status} ${formatTestPath(config, testPath)}` +
(testDetail.length ? ` (${testDetail.join(', ')})` : '')
`${status} ${projectDisplayName}${formatTestPath(
projectConfig ? projectConfig : globalConfig,
Copy link
Contributor

Choose a reason for hiding this comment

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

i'm a little worried about that. Is this for resolving the relative test path?

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'm not sure, but the behavior here should not change with this PR

@cpojer
Copy link
Member

cpojer commented Aug 22, 2017

Woohoo, this is awesome and @jkassens literally asked for this at FB just two hours ago.

Here is my opinion on the UX:

  1. I think the solution you have in the screenshot is fine: show the displayName for projects where it is there, omit it for the ones that aren't.
  2. This is a tough one. I'd probably print it out as the user specified and not try to uppercase the text in JS. People can choose to use all lowercase, all uppercase, or whatever @aaronabramov prefers for his projects.
  3. Emojis must be supported for sure. 💯

Overall, the three answers all point to: be lenient with the user, and allow them to customize and control this behavior without Jest exerting too much control.

@aaronabramov
Copy link
Contributor

or whatever @aaronabramov prefers for his projects.

just let it go haha 😃

what would be the strategy for emoji display name in non-terminal logs though?

// jest.conf.js
{
  displayName: isTTY ? 🦐 : 'i_like_underscores',
}

@cpojer
Copy link
Member

cpojer commented Aug 23, 2017

Uh.. yeah this is kinda bad because the transform cache is dependent on the ProjectConfig, so if this value changes on different runs, the cache will be wiped. I definitely would like to support emoji though :P We could allow both a string and object value for displayName, and normalize to the object in the normalize.js file, and then have something like {interactive: '🐛', default: 'TEXT'}?

@rogeliog
Copy link
Contributor Author

rogeliog commented Aug 23, 2017

So we are going for string|{default: string, interactive: string} right?

@rogeliog
Copy link
Contributor Author

rogeliog commented Aug 23, 2017

I wonder if it is better if we flip it, so that we have {default: '🐛', nonInteractive: 'TEXT'}

@aaronabramov
Copy link
Contributor

So we are going for string|{default:string, interactive: string} right?

yes for InitialOptions type and only {default: string, interactive: string} for ProjectConfig type

@cpojer
Copy link
Member

cpojer commented Aug 23, 2017

I think default + interactive works for me. I generally don't like negations in variable names.

@cpojer
Copy link
Member

cpojer commented Aug 23, 2017

Possible follow-up PR: should we also print the display name in the test suite typeahead in watch mode?

@rogeliog
Copy link
Contributor Author

rogeliog commented Aug 23, 2017

Got it, that makes sense!

Integrating this with the typeaheads would be nice!

@cpojer cpojer mentioned this pull request Aug 23, 2017
6 tasks
@rogeliog
Copy link
Contributor Author

rogeliog commented Aug 23, 2017

@thymikee Maybe I'm missing something, but does jest-validate support mixed types? I'm having some trouble with that

#4327 (comment)

@thymikee
Copy link
Collaborator

@rogeliog nope :(. For now you'll have to declare just one, without the feedback for the other.

@rogeliog
Copy link
Contributor Author

@cpojer @aaronabramov given @thymikee's comment, should we start with just displayName: string? or should we first add mixed types to jest-validate?

@thymikee
Copy link
Collaborator

I'd go with displayName: string and refactor later. This week is really busy for me, so I won't be able to implement it in nearest future :D

@cpojer
Copy link
Member

cpojer commented Aug 23, 2017

I'm fine if we merge this first, and then make the change. @aaronabramov can you review this and merge it? You are the expert on this code.

"
`;

exports[`can pass projects or global config 3`] = `
"PASS project1/__tests__/file1.test.js
"PASS BACKEND project1/__tests__/file1.test.js
PASS UI project3/__tests__/file1.test.js
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@aaronabramov There is a double space here... this happens in cases where we disable chalk... because we are doing

chalk.someOptions(` ${displayName} `)

Should we remove those extra spaces when chalk is disabled?

Copy link
Member

Choose a reason for hiding this comment

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

Yes, let's remove it in that case. Both on the left and right.

Copy link
Contributor Author

@rogeliog rogeliog Aug 25, 2017

Choose a reason for hiding this comment

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

I thought that only the displayName had the extra spaces but it seems that PASS/FAIL also have them already in master... so the fix might involve a bit more changes
screen shot 2017-08-24 at 11 16 33 pm

Copy link
Contributor Author

@rogeliog rogeliog Aug 25, 2017

Choose a reason for hiding this comment

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

Here is the diff for removing the extra spaces in PASS and FAIL rogeliog/jest@add-display-name...rogeliog:add-display-name-full-diff (Still need some work to make sure it works with CI=true jest --color)

@cpojer @aaronabramov I'm not sure if that leading space before PASS and the two after it are intentionally there in the current version or if it is fine to remove them? I'm fine with either I just wanted to understand if any of these current behavior was intentional... I'll update this PR after I get a better understanding on the expected behavior of non interactive non MPR output :) thanks!

Copy link
Member

Choose a reason for hiding this comment

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

I think it's fine to remove them when colors are disabled.

@codecov-io
Copy link

Codecov Report

Merging #4327 into master will increase coverage by <.01%.
The diff coverage is 71.42%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #4327      +/-   ##
==========================================
+ Coverage   55.85%   55.85%   +<.01%     
==========================================
  Files         189      189              
  Lines        6383     6393      +10     
  Branches        6        6              
==========================================
+ Hits         3565     3571       +6     
- Misses       2815     2819       +4     
  Partials        3        3
Impacted Files Coverage Δ
packages/jest-config/src/valid_config.js 100% <ø> (ø) ⬆️
packages/jest-config/src/index.js 0% <ø> (ø) ⬆️
packages/jest-config/src/normalize.js 78.26% <ø> (ø) ⬆️
...ackages/jest-cli/src/reporters/default_reporter.js 91.04% <100%> (ø) ⬆️
packages/jest-cli/src/reporters/Status.js 93.93% <100%> (+0.18%) ⬆️
...ckages/jest-cli/src/reporters/get_result_header.js 82.35% <100%> (+3.78%) ⬆️
packages/jest-cli/src/reporters/utils.js 60.39% <20%> (-2.11%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update db4465e...fdb0d1f. Read the comment docs.

@cpojer cpojer merged commit e535665 into jestjs:master Aug 27, 2017
@cpojer
Copy link
Member

cpojer commented Aug 27, 2017

Nice work @rogeliog, thank you!

@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 13, 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.

project name in MP Runner
6 participants