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

Breakpoint set but not yet bound in VUE app #860

Closed
SergioEanX opened this issue Nov 18, 2020 · 4 comments
Closed

Breakpoint set but not yet bound in VUE app #860

SergioEanX opened this issue Nov 18, 2020 · 4 comments
Assignees
Labels
bug Issue identified by VS Code Team member as probable bug *duplicate Issue identified as a duplicate of another issue(s)

Comments

@SergioEanX
Copy link

SergioEanX commented Nov 18, 2020

I'm experiencing several issues in trying to debug a VUE app.
The VUE app is available here.
I'm using node v14.15.0 and @vue/cli 4.5.9.
The main issue is regarding "breakpoint set but not yet bound" or erratic behaviour of the debugger that in a try/catch block does not show error value (on mouseover) but has no issues using promises (more here).

To Reproduce
Open ExternalApi.vue inside src/components and place two breakpoints at line 44 and 60 (as an example).
I slightly changed this file, respect to the code at link above, in:

<script>
export default {
  name: "Api",
  data() {
    return {
      apiMessage: null,
      executed: false,
    };
  },
  methods: {
    async callApi2() {
      this.executed = true;
      try {
        const { data } = await this.$http.get(
          "https://gorest.co.in/public-api/posts5"
        );

        this.apiMessage = data;
      } catch (error) {
        this.apiMessage = error.stack;
      }
    },

    callApi() {
      this.executed = true;

      const accessToken = "gjkgkjgk"; //await this.$auth.getTokenSilently();
      this.$http
        .get("/api/external", {
          headers: {
            Authorization: `Bearer ${accessToken}`,
          },
        })
        .then((data) => (this.apiMessage = data))
        .catch(
          (error) =>
            //console.log(err);
            (this.apiMessage = `Error: the server responded with '${error.response.status}: ${error.response.statusText}'`)
        );
    },
  },
};
</script>

I suppose that it is a problem related to launch.json and/or tasks.json.
File launch.json is:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "chrome",
      "request": "launch",
      "name": "vuejs: chrome",
      "url": "http://localhost:3000",
      "webRoot": "${workspaceFolder}/src",
      "breakOnLoad": true,
      "trace":true,
      "pathMapping": {
        "/_karma_webpack_": "${workspaceFolder}"
      },
      // "sourceMapPathOverrides": {
      //   "webpack:/*": "${webRoot}/*",
      //   "/./*": "${webRoot}/*",
      //   "/src/*": "${webRoot}/*",
      //   "/*": "*",
      //   "/./~/*": "${webRoot}/node_modules/*"
      // },
      "sourceMapPathOverrides": {
        "webpack:///./*": "${webRoot}/*",
        "webpack:///src/*": "${webRoot}/*",
        "webpack:///*": "*",
        "webpack:///./~/*": "${webRoot}/node_modules/*",
        "meteor://💻app/*": "${webRoot}/*"
      },
      "preLaunchTask": "serve"
    }
  ]
}

While tasks.json is:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "serve",
      "type": "npm",
      "script": "serve-vue",
      "isBackground": true,
      "problemMatcher": [
        {
          "base": "$tsc-watch",
          "background": {
            "activeOnStart": true,
            "beginsPattern": "Starting development server",
            "endsPattern": "Compiled successfully"
          }
        }
      ],
      "group": {
        "kind": "build",
        "isDefault": true
      }
    }
  ]
}

VS Code has "ms-vscode.js-debug" set not enable and "ms-vscode.js-debug-nightly" installed and enabled.
If property "debug.javascript.usePreview= false" is set in settings.json I experience the "breakpoint set but not yet bound", while if this property is not set at all I experience a weird behaviour that in an async/await function with a try/catch block (as above in callApi2) I can't see error value on mouseover, but the breakpoint is set and the debugger jumps to the correct location.
What's wrong?
Thanks.

Log File
vscode-chrome-debug.txt

VS Code Version: 1.51.1

@SergioEanX SergioEanX added the bug Issue identified by VS Code Team member as probable bug label Nov 18, 2020
@connor4312
Copy link
Member

connor4312 commented Nov 18, 2020

If property "debug.javascript.usePreview= false" is set in settings.json I experience the "breakpoint set but not yet bound"

This is expected in the old debugger since Vue needs to be treated specially in some cases, and it did not.

I can't see error value on mouseover, but the breakpoint is set and the debugger jumps to the correct location.

It looks like the repo is downleveling async to ES5, which has the side effect of renaming the "error" variable.

return regeneratorRuntime.wrap(function _callee$(_context) {
    while (1) {
      switch (_context.prev = _context.next) {
        case 0:
        this.executed = true;
        _context.prev = 1;
        _context.next = 4;
        return this.$http.get("https://gorest.co.in/public-api/posts5");
        
      case 4:
        _yield$this$$http$get = _context.sent;
        data = _yield$this$$http$get.data;
        this.apiMessage = data;
        _context.next = 12;
        break;
        
      case 9:
        _context.prev = 9;
        _context.t0 = _context["catch"](1);
        this.apiMessage = _context.t0.stack;
        
      case 12:
      case "end":
        return _context.stop();
    }
  }
}, _callee, this, [[1, 9]]);

So at the point of "catch", that variable doesn't exist. async/await is supported in all modern browsers, so I recommend changing your build to not downlevel like this.

Automatically dealing with renames like this (when sourcemaps support it) can be tracked in microsoft/vscode#12066, thus closing as a duplicate of that feature request.

@connor4312 connor4312 added the *duplicate Issue identified as a duplicate of another issue(s) label Nov 18, 2020
@SergioEanX
Copy link
Author

Could you further clearify what do you mean for "change your build" ? It is an issue due to @auth0/auth0-spa-js module? Or I have to change node version?
Thanks

@connor4312
Copy link
Member

It looks like that app uses a .browserslistrc to configure what browsers/platforms it targets. Playing with that to not downlevel await can get you what you're after.

Or if you actually want to target these older browsers (namely IE) you can leave it as is and look in the "Variables" view on the sidebar which will show function locations, which will include whatever the error variable was renamed to.

@SergioEanX
Copy link
Author

I changed my .browserslistrc from:

> 1%
last 2 versions
not dead

to

defaults
not IE 11
not IE_Mob 11
maintained node versions

But with no results.
Could be a problem of babel.config.js ?
It' simply:

module.exports = {
  presets: ["@vue/app"],
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issue identified by VS Code Team member as probable bug *duplicate Issue identified as a duplicate of another issue(s)
Projects
None yet
Development

No branches or pull requests

2 participants