debugging nightmare - how to disable babel async/await transpiling



  • Framefork is awesome. Babel transpiling is nightmare. When I started debugging async/await code I got a lot of pain with random jumping lines in my phpstorm. Can’t get any relevant information how to solve the problem on weird transpiling system.

    Can any one help with subject? How to disable(or fix somehow) transpiling in babel(it’s ok for me during dev have async/await in chrome).

    It’s hard to solve, cause I don’t really understans babel and it’s configs.

    Searched exact tips - but no luck…

    Thank you in advance



  • I disabled supportIE in quasar.conf.js

    // https://quasar.dev/quasar-cli/cli-documentation/supporting-ie
        supportIE: false,
    

    But still no luck.
    I’ll appreciate any help.



  • tried to exclude some plugins using babel.config.js

    module.exports = {
      "presets": [
        [
          "@quasar/babel-preset-app",
          {
            "exclude": ["babel-plugin-transform-async-to-generator", "babel-plugin-transform-regenerator",'asdfac']
          }
        ]
      ],
    }
    

    Still no luck. Looks like this doesn’t exclude anything…



  • Main problem for me during debugging that this code:

    async getDocumentList(){
            let docList = await axios.get(null, {
              params: {
                "cmd": "DocsSearchByDateSend",
                "DT1": this.dateInterval.D1,
                "DT2": this.dateInterval.D2,
                //"IdOrg ": get from slctOrg component ? using emit?
              }, headers: {}
            });
            if (docList && docList.status == 200){
              this.docs = docList.data ? docList.data : [];
            }
          }
    

    during debug gets into runtime.js

      // Try/catch helper to minimize deoptimizations. Returns a completion
      // record like context.tryEntries[i].completion. This interface could
      // have been (and was previously) designed to take a closure to be
      // invoked without arguments, but in all the cases we care about we
      // already have an existing method we want to call, so there's no need
      // to create a new function object. We can even get away with assuming
      // the method takes exactly one argument, since that happens to be true
      // in every case, so we don't have to touch the arguments object. The
      // only additional allocation required is the completion record, which
      // has a stable shape and so hopefully should be cheap to allocate.
      function tryCatch(fn, obj, arg) {
        try {
          return { type: "normal", arg: fn.call(obj, arg) };
        } catch (err) {
          return { type: "throw", arg: err };
        }
      }
    

    istead of just jump to second string after await.
    How can I fix this behavior during debugging?



  • No luck. I’ll appreciate any help.


Log in to reply