-
-
Notifications
You must be signed in to change notification settings - Fork 6.4k
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
fix: add console error to catch block #6665
Conversation
Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need the corporate CLA signed. If you have received this in error or have any questions, please contact us at [email protected]. Thanks! |
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks! |
Codecov Report
@@ Coverage Diff @@
## master #6665 +/- ##
==========================================
+ Coverage 63.73% 63.74% +<.01%
==========================================
Files 235 235
Lines 8940 8941 +1
Branches 4 3 -1
==========================================
+ Hits 5698 5699 +1
Misses 3241 3241
Partials 1 1
Continue to review full report at Codecov.
|
@@ -47,7 +47,9 @@ class DependencyResolver { | |||
} | |||
try { | |||
return this._resolver.resolveModule(file, dependency, options); | |||
} catch (e) {} | |||
} catch (e) { | |||
console.error(e); |
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'm not sure why we fallback to mock module here... I think a better approach would be to just rethrow the error unless we want to fetch the mock.
This is pretty old code (from #1007) @cpojer why would we want to swallow that error? @J-Dickson Could you add a test which shows how this error was previously swallowed? An integration test asserting on |
IIRC the error is swallowed, because we handle it somewhat later (e.g. file doesn't exists on FS because it's a mock). Try to checkout this PR locally and see what happens when you run |
Yup, but there are scenarios in which this causes the @SimenB yeah, no worries. I will write one when I get a little bit of free time. The issue I had was basically imports with paths that could not be found. |
@J-Dickson have you tried with this patch? #6407 |
Sorry for the late response, seems like that should work, yeah! Thanks, will close the PR. |
Available in |
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
I had an issue recently where the jest-resolve-dependencies was swallowing errors in the catch statement. The error was actually causing the
jest --watch
command to hang, I thought that it'd be helpful for users to see the errors so that they are able to rectify them.I found that errors were being swallowed from the following: #6025
Test plan
No tests added for a
console.error