-
-
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
sets project name if empty fixes #5597 #5862
Conversation
The tests do not pass right now because I am having trouble with the types. If anyone has advice I would appreciate it. |
Huh, I had no idea |
options.projects = (options.projects || []).map( | ||
(project: string | ProjectConfig, index) => { | ||
if (!typeof project !== 'string' && !project.hasOwnProperty('name')) { | ||
project.name = crypto |
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 seems to fail on CI: https://circleci.com/gh/facebook/jest/17682
@@ -0,0 +1,9 @@ | |||
|
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 directory shouldn't be checked in (it's created by integration tests)
Thanks for the fix! I'm a bit worried that this diff will only fix this issue for uses of the multi project runner where the config objects are passed in but it won't work when specifying multiple paths to various configuration files. |
@cpojer I think I can see what you are getting at. I spiked combining https://github.com/facebook/jest/blob/master/packages/jest-cli/src/cli/index.js#L228 and https://github.com/facebook/jest/blob/master/packages/jest-cli/src/cli/index.js#L248 to something like: if (projects.length > 0) {
const parsedConfigs = projects
.filter(root => {
if (
typeof root === 'string' &&
fs.existsSync(root) &&
!fs.lstatSync(root).isDirectory() &&
!root.endsWith('.js') &&
!root.endsWith('.json')
) {
return false;
}
return true;
})
// readConfig recursively finds project paths by looking in `parsedConfig.projects` `globalConfig.projects` and parses them as usual
.map(root => readConfig(argv, root, true, configPath))
.flatten();
...
} but I could not find a solution that I was happy with. |
It looks like the only failing test is a test that is failing in master. |
Failing test tracked in #5871 |
@cbelsole you are right, I think that's the right location to make this change. What exactly were you not sure about? |
@cpojer I needed more background on how the config path was being passed in. It was not being set for me when I needed it to. So I backed that change out as to not blow up the scope of this pr. |
@cbelsole do you think we could land this? Maybe @paularmstrong has some thoughts on Christoph's suggestion? |
I'm not sure I understand @cpojer's request. For me as an end-user: as long as it works, I'm happy :) Currently working around this by manually specifying project |
@cbelsole ping 🙂 |
if (!options.name) { | ||
options.name = crypto | ||
.createHash('md5') | ||
.update(options.rootDir) | ||
.digest('hex'); | ||
} | ||
|
||
if (Array.isArray(options.projects)) { | ||
options.projects = options.projects.map((project, index) => { |
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.
normalize
is run on every project config, once per run, data is not persisted. I don't think it's necessary to double loop like this. Seems like simply adding a timestamp to the equation fixes the problem (or maybe I'm missing a bigger picture @SimenB):
diff --git a/packages/jest-config/src/normalize.js b/packages/jest-config/src/normalize.js
index 713c8b0da..11d61e080 100644
--- a/packages/jest-config/src/normalize.js
+++ b/packages/jest-config/src/normalize.js
@@ -270,6 +270,7 @@ const normalizeMissingOptions = (options: InitialOptions): InitialOptions => {
options.name = crypto
.createHash('md5')
.update(options.rootDir)
+ .update(Date.now().toString())
.digest('hex');
}
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.
Math.random()
seems safer in case the loop completes in less than 1ms, but I agree that should probably solve it as well
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.
Agreed. I'd go with uuid/v4
for generating random number though, as Math.random
is not so random after all and I'd hate to debug issue like this 😅.
Tested it locally and it fixes the issue (on Node 8, this particular example is not reproducible on Node 10)
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.
@thymikee which double loop do you mean? It's just a single loop through projects
, isn't it?
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.
@thymikee which double loop do you mean? It's just a single loop through projects, isn't it?
normalize
is run for every project config, so essentially we loop through projects
once again here, hence double loop. And the solution I proposed doesn't have this issue.
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.
Push it? 😀 I fixed my Set
comment, would be nice to get this fix into Jest 24
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.
Done. I checked the repro and it still works as expected. I should probably add an e2e test to be sure.
@@ -399,3 +399,41 @@ test('Does transform files with the corresponding project transformer', () => { | |||
expect(stderr).toMatch('PASS project1/__tests__/project1.test.js'); | |||
expect(stderr).toMatch('PASS project2/__tests__/project2.test.js'); | |||
}); | |||
|
|||
test("doesn't bleed module file extensions resolution with multiple workers", () => { |
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.
While running a repro again, I discovered this only happens when we run multiple workers, so added this test. It fails without uuid
.
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
When a project name does not exist it uses the name based on the main rootDir. This causes the incorrect resolver to be selected since all projects names resolve the same. The fix is to create a unique name for projects that do not have one.
fixes: #5597
Test plan
Added unit test: