When targeting & debugging NodeJS, hovering the mouse just gives me a snippet with the variable declaration.
Adding it to watches via this.variable_name results in “Uncaught TypeError. Cannot read properties of undefined etc etc”. (which makes sense because “this” is undefined in the anonymous context)
But then what can we use to watch a variable? I tried just the name of the variable that that never works (not even outside of anonymous functions).
VS code watches have been a pain to use with Haxe because always having to add this. in front of everything, but this is even worse because I can’t watch a variable at all in anonymous functions, at least from what I see so far.
As someone who has developed VSCode extensions, I can say that it’s up to every debug adapter extension to implement each individual debugging feature, and it is not required to implement everything that VSCode supports. I would expect JS debug adapters (Chrome, Firefox, etc) to work the best, since they are used much more widely in the web community (with pure JS, TypeScript, etc). However, I honestly wouldn’t be surprised if debug adapters for more Haxe-specific runtimes/targets like hxcpp and HashLink may be missing features, or have incomplete implementations, since they are less widely used.
Hey @joshtynjala :). Thanks for answering. It’s in JS, yes. I forgot to mention that
Debugging works decently I think. A bit annoying to have to use “this” to access any class variables (I think the extension should default to that like in TS).
But anonymous function watches don’t work at all, and hovering on symbols often fails to produce any result. I guess I should report the issue to the extension team. I thought I’m missing something but this may be a bug. Or more like missing feature. And I think it’s a pretty important feature.
Interesting. If you’re targeting JS, then presumably you’re using Microsoft’s official JS debugger extension for VSCode. I’m not aware of a Haxe-centric extension that is specifically for debugging JS. Microsoft’s JS debugger is designed to be used with any compile-to-JS language, thanks to source maps. So maybe it’s a difference in the source maps that the Haxe compiler generates vs the ones that the TS compiler generates.
Probably a dumb question, but you did tell the Haxe compiler to generate source maps, right?
