-
-
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
feat: warn when there are multiple configs #11922
feat: warn when there are multiple configs #11922
Conversation
Just thinking out loud. What if Jest would simply This wouldn’t be a breaking change in this case. (Would be good to check how this shall work with projects.) |
I just followed this comment by maintainers: #10798 (review) . I don't have strong feelings about 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.
lgtm.
One thing is that if people define a --config
flag this should not throw. We should only error if Jest needs to traverse and find configuration on its own and there is ambiguity on which to use.
I'd also like to see some integration tests for this (i.e. a dir with both a config file and config in package.json, and run it once to see the error, then with --config jets.config.js
which should not throw)
Co-authored-by: Simen Bekkhus <[email protected]>
Sorry, missed that. On it.
I will leave that decision to you. I like error a bit more, but I don't have the knowledge about |
Added e2e test for that (surprisingly there wasn't one - at least I didn't find any). |
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, this looks great! I just have a couple of nits for the tests, beyond that LGTM 👍
Co-authored-by: Simen Bekkhus <[email protected]>
…nKaifer/jest into jankaifer/warn-multiple-configs-found
packages/jest-config/src/__tests__/__snapshots__/resolveConfigPath.test.ts.snap
Outdated
Show resolved
Hide resolved
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.
Ok, I think we're almost done now 😀
(remember the changelog entry)
} | ||
|
||
if (configFiles.length > 1) { | ||
throw new Error(makeMultipleConfigsError(configFiles)); |
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.
if we throw it's a breaking change, and we need to wait for Jest 28. Thoughts on making it a warning for now so we can land it, then throw later?
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.
Sounds reasonable.
Should I hide it behind a flag? Or just delete it and rewrite it for warnings?
This question is related to tests, the code itself is just one line, but tests are completely different.
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'd do console.warn
instead of throwing, make the unit tests mock out the console, while the e2e test is essentially the same except for the exit code
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.
resolveConfigPath
has to be a pure function (no console.warn
there), because it is run multiple times.
There is hasDeprecationWarnings: boolean
flag somewhere. I will look into it later.
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.
hasDeprecationWarnings
has no text associated with it.
The best solution I found was to propagate shouldLogWarnings
. But I'm not sure it is good enough.
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.
The "second" usage is here: https://github.com/facebook/jest/blob/a22ed6592f772df6b19314d9f06a7285c3b0968b/packages/jest-config/src/index.ts#L287
It's reading jest config to determine if there are any additional projects defined.
And then it is called again for each project.
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.
@SimenB ^ this one is still not solved.
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.
gave that a whack with 6a52634
(#11922)
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.
Ok, so you went with shouldLogWarnings
. 👍
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, it was either that or store some list of the exact warning we had logged (a Set
to dedupe) then only log after all configs were resolved. This seemed cleaner
Co-authored-by: Simen Bekkhus <[email protected]>
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! is a fantastic first contribution 🎉
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.
got a bit too eager, didn't notice the failing tests 😅
Co-authored-by: Simen Bekkhus <[email protected]>
Sorry, was busy with school. Thanks for finishing it @SimenB. And thanks for guiding me through this 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.
Now it seems CI is happy. Thanks again!
Codecov Report
@@ Coverage Diff @@
## main #11922 +/- ##
==========================================
+ Coverage 68.75% 68.78% +0.03%
==========================================
Files 322 322
Lines 16587 16608 +21
Branches 4787 4793 +6
==========================================
+ Hits 11404 11424 +20
- Misses 5151 5152 +1
Partials 32 32
Continue to review full report at Codecov.
|
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
resolveConfigPath
throws when there are bothpackage.json
(with "jest") andjest.config.ext
present in a single directory.Fix #10124
There are 2 stale PRs that I took inspiration from: #10798 and #10213
It is a breaking change (error, not a warning) as proposed by @SimenB here: #10798 (review)
Closes #10798
Closes #10213
Test plan
I wrote/updated unit tests that check the behavior.
Questions
package.json
needs to have"jest"
key in order to be a valid jest config file.package.json
don't know if that could be a performance problem."jest"
is hardcoded in two places now: https://github.com/facebook/jest/blob/7109b8ccea2e0f70b6ad8eae02cd36b6c2841604/packages/jest-config/src/readConfigFileAndSetRootDir.ts#L58 . I'm not sure where to move it.