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

Stack trace with wrong line number #7402

Closed
fotonmoton opened this issue Nov 23, 2018 · 13 comments
Closed

Stack trace with wrong line number #7402

fotonmoton opened this issue Nov 23, 2018 · 13 comments

Comments

@fotonmoton
Copy link

🐛 Bug Report

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 #6108 or #6556 or #6424, but I can reproduce this bug with and without watch mode.

image

To Reproduce

Don't know what exactly causes this issue. Simply run yarn jest or yarn jest --watch

Expected behavior

Jest will point to right line that caused error.

Link to repl or repo (highly encouraged)

Here is repo with buggy test.

Run npx envinfo --preset jest

npx: 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
@rickhanlonii
Copy link
Member

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:

screenshot 2018-11-25 23 32 51

Thoughts @SimenB? You're the goto code frame expert

@rickhanlonii
Copy link
Member

Also broken on master

@fotonmoton
Copy link
Author

@rickhanlonii thanks!
If I can help somehow please write me, because this bug annoys me too much :)

@SimenB
Copy link
Member

SimenB commented Nov 26, 2018

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.

image

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 @@ resolve@1.1.7:
   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==

@rickhanlonii
Copy link
Member

@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?

@SimenB
Copy link
Member

SimenB commented Nov 26, 2018

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

@fotonmoton
Copy link
Author

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

@SimenB
Copy link
Member

SimenB commented Nov 26, 2018

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

@fotonmoton
Copy link
Author

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:
image

@SimenB
Copy link
Member

SimenB commented Nov 26, 2018

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

ArtemGovorov added a commit to ArtemGovorov/node-source-map-support that referenced this issue Feb 22, 2019
…eFile` functions

The `handlerExec` function produces functions that are using original `retrieveFileHandlers`/`retrieveMapHandlers` references, so because the array variables are  re-assigned in the `resetRetrieveHandlers` function, `retrieveSourceMap` and `retrieveFile` need to be re-created to point them to correct instances of `retrieveFileHandlers`/`retrieveMapHandlers`.

This fixes:
jestjs/jest#6424
jestjs/jest#7402
@ArtemGovorov
Copy link
Contributor

there's a bug in source-map-support not 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 #6424.

@SimenB
Copy link
Member

SimenB commented Feb 11, 2022

Removing lockfile to get new stuff and updating Jest to latest (27.5.1 at time of writing) fixes the error reported in #7402 (comment).

(possibly fixed by above PR)

If there are still bugs, please open up a new issue 🙂

@SimenB SimenB closed this as completed Feb 11, 2022
@github-actions
Copy link

This issue 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 Mar 14, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants