Promise-based test (maybe not only promise-based) fails with wrong stack trace (jest points to wrong line number). Maybe this issue somehow related to https://github.com/facebook/jest/issues/6108 or https://github.com/facebook/jest/issues/6556 or https://github.com/facebook/jest/issues/6424, but I can reproduce this bug with and without watch mode.

Don't know what exactly causes this issue. Simply run yarn jest or yarn jest --watch
Jest will point to right line that caused error.
Here is repo with buggy test.
npx envinfo --preset jestnpx: installed 1 in 1.425s
System:
OS: Linux 4.15 Ubuntu 18.04.1 LTS (Bionic Beaver)
CPU: (8) x64 Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
Binaries:
Node: 8.12.0 - /usr/bin/node
Yarn: 1.12.3 - /usr/bin/yarn
npm: 6.4.1 - /usr/bin/npm
npmPackages:
jest: ^23.6.0 => 23.6.0
Great bug report @fotonmoton, thanks for including all the info
Confirmed, and note that this is also broken on Babel 6. Failure looks like this:

Thoughts @SimenB? You're the goto code frame expert
Also broken on master
@rickhanlonii thanks!
If I can help somehow please write me, because this bug annoys me too much :)
This is difficult since the error is thrown in an injected babel helper which is also in the test file. I'm not sure what heuristic beyond hardcoding function names would give the correct behavior here. Just ignoring functions starting with underscore feels like a hammer.
@fotonmoton a workaround is to import the helpers instead of injecting them.

Still not perfect, but that's what the sourcemap gives us...
diff --git i/.babelrc w/.babelrc
index 69fe715..13cf491 100644
--- i/.babelrc
+++ w/.babelrc
@@ -1,3 +1,4 @@
{
+ "plugins": ["@babel/plugin-transform-runtime"],
"presets": ["@babel/preset-env"]
}
diff --git i/package.json w/package.json
index a373244..5e7c224 100644
--- i/package.json
+++ w/package.json
@@ -1,7 +1,10 @@
{
"devDependencies": {
"@babel/core": "^7.1.6",
+ "@babel/plugin-transform-runtime": "^7.1.0",
"@babel/preset-env": "^7.1.6",
+ "@babel/runtime": "^7.1.5",
+ "babel-core": "^7.0.0-0",
"babel-jest": "^23.6.0",
"jest": "^23.6.0"
}
diff --git i/yarn.lock w/yarn.lock
index 1b39ec5..ecfa35f 100644
--- i/yarn.lock
+++ w/yarn.lock
@@ -457,6 +457,16 @@
dependencies:
regenerator-transform "^0.13.3"
+"@babel/plugin-transform-runtime@^7.1.0":
+ version "7.1.0"
+ resolved "https://registry.yarnpkg.com/@babel/plugin-transform-runtime/-/plugin-transform-runtime-7.1.0.tgz#9f76920d42551bb577e2dc594df229b5f7624b63"
+ integrity sha512-WFLMgzu5DLQEah0lKTJzYb14vd6UiES7PTnXcvrPZ1VrwFeJ+mTbvr65fFAsXYMt2bIoOoC0jk76zY1S7HZjUg==
+ dependencies:
+ "@babel/helper-module-imports" "^7.0.0"
+ "@babel/helper-plugin-utils" "^7.0.0"
+ resolve "^1.8.1"
+ semver "^5.5.1"
+
"@babel/plugin-transform-shorthand-properties@^7.0.0":
version "7.0.0"
resolved "https://registry.yarnpkg.com/@babel/plugin-transform-shorthand-properties/-/plugin-transform-shorthand-properties-7.0.0.tgz#85f8af592dcc07647541a0350e8c95c7bf419d15"
@@ -550,6 +560,13 @@
js-levenshtein "^1.1.3"
semver "^5.3.0"
+"@babel/runtime@^7.1.5":
+ version "7.1.5"
+ resolved "https://registry.yarnpkg.com/@babel/runtime/-/runtime-7.1.5.tgz#4170907641cf1f61508f563ece3725150cc6fe39"
+ integrity sha512-xKnPpXG/pvK1B90JkwwxSGii90rQGKtzcMt2gI5G6+M0REXaq6rOHsGC2ay6/d0Uje7zzvSzjEzfR3ENhFlrfA==
+ dependencies:
+ regenerator-runtime "^0.12.0"
+
"@babel/template@^7.1.0", "@babel/template@^7.1.2":
version "7.1.2"
resolved "https://registry.yarnpkg.com/@babel/template/-/template-7.1.2.tgz#090484a574fef5a2d2d7726a674eceda5c5b5644"
@@ -818,6 +835,11 @@ babel-core@^6.0.0, babel-core@^6.26.0:
slash "^1.0.0"
source-map "^0.5.7"
+babel-core@^7.0.0-0:
+ version "7.0.0-bridge.0"
+ resolved "https://registry.yarnpkg.com/babel-core/-/babel-core-7.0.0-bridge.0.tgz#95a492ddd90f9b4e9a4a1da14eb335b87b634ece"
+ integrity sha512-poPX9mZH/5CSanm50Q+1toVci6pv5KSRv/5TWCwtzQS5XEwn40BcCrgIeMFWP9CKKIniKXNxoIOnOq4VVlGXhg==
+
babel-generator@^6.18.0, babel-generator@^6.26.0:
version "6.26.1"
resolved "https://registry.yarnpkg.com/babel-generator/-/babel-generator-6.26.1.tgz#1844408d3b8f0d35a404ea7ac180f087a601bd90"
@@ -3444,6 +3466,11 @@ regenerator-runtime@^0.11.0:
resolved "https://registry.yarnpkg.com/regenerator-runtime/-/regenerator-runtime-0.11.1.tgz#be05ad7f9bf7d22e056f9726cee5017fbf19e2e9"
integrity sha512-MguG95oij0fC3QV3URf4V2SDYGJhJnJGqvIIgdECeODCT98wSWDAJ94SSuVpYQUoTcGUIL6L4yNB7j1DFFHSBg==
+regenerator-runtime@^0.12.0:
+ version "0.12.1"
+ resolved "https://registry.yarnpkg.com/regenerator-runtime/-/regenerator-runtime-0.12.1.tgz#fa1a71544764c036f8c49b13a08b2594c9f8a0de"
+ integrity sha512-odxIc1/vDlo4iZcfXqRYFj0vpXFNoGdKMAUieAlFYO6m/nl5e9KR/beGf41z4a1FI+aQgtjhuaSlDxQ0hmkrHg==
+
regenerator-transform@^0.13.3:
version "0.13.3"
resolved "https://registry.yarnpkg.com/regenerator-transform/-/regenerator-transform-0.13.3.tgz#264bd9ff38a8ce24b06e0636496b2c856b57bcbb"
@@ -3586,7 +3613,7 @@ [email protected]:
resolved "https://registry.yarnpkg.com/resolve/-/resolve-1.1.7.tgz#203114d82ad2c5ed9e8e0411b3932875e889e97b"
integrity sha1-IDEU2CrSxe2ejgQRs5ModeiJ6Xs=
-resolve@^1.3.2:
+resolve@^1.3.2, resolve@^1.8.1:
version "1.8.1"
resolved "https://registry.yarnpkg.com/resolve/-/resolve-1.8.1.tgz#82f1ec19a423ac1fbd080b0bab06ba36e84a7a26"
integrity sha512-AicPrAC7Qu1JxPCZ9ZgCZlY35QgFnNqc+0LtbRNxnVw4TXvjQ72wnuL9JQcEBgXkI9JM8MsT9kaQoHcpCRJOYA==
@@ -3648,7 +3675,7 @@ sax@^1.2.4:
resolved "https://registry.yarnpkg.com/sax/-/sax-1.2.4.tgz#2816234e2378bddc4e5354fab5caa895df7100d9"
integrity sha512-NqVDv9TpANUjFm0N8uM5GxL36UgKi9/atZw+x7YFnQ8ckwFGKrl4xX4yWtrey3UJm5nP1kUbnYgLopqWNSRhWw==
-"semver@2 || 3 || 4 || 5", semver@^5.3.0, semver@^5.4.1, semver@^5.5.0:
+"semver@2 || 3 || 4 || 5", semver@^5.3.0, semver@^5.4.1, semver@^5.5.0, semver@^5.5.1:
version "5.6.0"
resolved "https://registry.yarnpkg.com/semver/-/semver-5.6.0.tgz#7e74256fbaa49c75aa7c7a205cc22799cac80004"
integrity sha512-RS9R6R35NYgQn++fkDWaOmqGoj4Ek9gGs+DPxNUZKuwE183xjJroKvyo1IzVFeXvUrvmALy6FWD5xrdJT25gMg==
@SimenB ah yeah that makes sense - is it possible for us to detect that it happened inside an injected helper and show a message indicating as much?
We could keep a list of the named babel helpers and skip them for the frame. Same with the typescript utils, I guess (for people using tsc instead of babel 7). Not sure how feasible that is? Some danger for false positives
@SimenB thanks, workaround works like a charm.
But why you add "babel-core": "^7.0.0-0", to package.json? I only add "@babel/plugin-transform-runtime": "^7.1.0" and "@babel/runtime": "^7.1.5" packages and add @babel/plugin-transform-runtime to babel plugins.
But why you add
"babel-core": "^7.0.0-0", to package.json?
See Babel 7 docs: https://jestjs.io/docs/en/getting-started#using-babel
I update repo so that deps match the docs. Also add another test where @SimenB workaround doesn't help, if error occurs outside describe/it scope:

The stack trace says 11:48, which is where we point at. Nothing else we can do in Jest to mitigate this. Either the sourcemaps produced by babel are too imprecise or there's a bug in source-map-support not mapping back properly
there's a bug in
source-map-supportnot mapping back properly
@SimenB It is indeed the case.
Looks like the bug was introduced in source-map-support by this pull request. I have created the pull request to fix it. It should also address https://github.com/facebook/jest/issues/6424.
Most helpful comment
@SimenB It is indeed the case.
Looks like the bug was introduced in
source-map-supportby this pull request. I have created the pull request to fix it. It should also address https://github.com/facebook/jest/issues/6424.