Composer, developer, husband, VR enthusiast, cat whisperer. Known for my work on the Mass Effect trilogy. Co-founder/CEO/CTO of ReelCrafter, Techstars Chicago alum, AWS Community Builder.
Debugging async/await is actually a total pain if you're working in a project that's using babel. If you're stepping through your code, the minute you hit an async call, you're thrown into polyfill. If you're aware of a workaround, I'd love to know about it!
Composer, developer, husband, VR enthusiast, cat whisperer. Known for my work on the Mass Effect trilogy. Co-founder/CEO/CTO of ReelCrafter, Techstars Chicago alum, AWS Community Builder.
For context, this is in a Vue project (created with vue-cli 3), and it's in a local dev environment so source maps shouldn't matter I don't think? I'll have to do another test with this and see if it's still an issue.
Disable that in Babel and let it spit out the actual async/await code instead of polyfilling it. (I do that for various other features as well, HTML custom elements being a big one, since there isn't a good way to write those in an ES3 compatible manner; new.target and Reflect didn't become available until after classes, and since you need to call 'super()' or equivalent in the constructor...)
Combined with webpack or the like, I'm not sure there, I have yet to use it.
Composer, developer, husband, VR enthusiast, cat whisperer. Known for my work on the Mass Effect trilogy. Co-founder/CEO/CTO of ReelCrafter, Techstars Chicago alum, AWS Community Builder.
I get that entirely, but for the initial testing and debugging of such code, I'd still turn it off. It lets you get your logic in order without having to debug a polyfill at the same time.
Composer, developer, husband, VR enthusiast, cat whisperer. Known for my work on the Mass Effect trilogy. Co-founder/CEO/CTO of ReelCrafter, Techstars Chicago alum, AWS Community Builder.
Debugging async/await is actually a total pain if you're working in a project that's using babel. If you're stepping through your code, the minute you hit an async call, you're thrown into polyfill. If you're aware of a workaround, I'd love to know about it!
That's interesting I don't think I had this problem. Do you have source maps enabled?
For context, this is in a Vue project (created with vue-cli 3), and it's in a local dev environment so source maps shouldn't matter I don't think? I'll have to do another test with this and see if it's still an issue.
Disable that in Babel and let it spit out the actual async/await code instead of polyfilling it. (I do that for various other features as well, HTML custom elements being a big one, since there isn't a good way to write those in an ES3 compatible manner; new.target and Reflect didn't become available until after classes, and since you need to call 'super()' or equivalent in the constructor...)
Combined with webpack or the like, I'm not sure there, I have yet to use it.
Not all browsers that I need to support can use async/await, unfortunately, so I need to let babel handle that still.
I get that entirely, but for the initial testing and debugging of such code, I'd still turn it off. It lets you get your logic in order without having to debug a polyfill at the same time.
Ah, I gotcha - just for the purpose of debugging. Makes sense!
Hi, this is probably a silly question, but how do you disable those generators in Babel? Thanks