microsoft / vscode-js-debug

A DAP-compatible JavaScript debugger. Used in VS Code, VS, + more
MIT License
1.67k stars 282 forks source link

Breakpoint set but not yet bound in VUE app #860

Closed SergioEanX closed 4 years ago

SergioEanX commented 4 years ago

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

connor4312 commented 4 years ago

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 https://github.com/microsoft/vscode/issues/12066, thus closing as a duplicate of that feature request.

SergioEanX commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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"],
}