"Debugging with WebStorm" recipe vs latest WebStorm 2018.1.2
erikkemperman opened this issue · 23 comments
Description
Trying to follow this recipe in latest WebStorm, 2018.1.2. It appears as though JetBrains are now doing some internal cleverness around debug ports and perhaps the recipe ought to reflect this.
The section "Setup using Node.js" works as advertised, although it appears the --debug-brk or --inspect-brk Node options in the "Edit configurations" dialog no longer have to be explicitly provided by the user (although it doesn't hurt if I do, it simply replaces my option with its own along with its port).
The section "Setup using NPM" however does not work as advertised. To get things to work I have to change my package.json from
"scripts": { "test": "ava ..." }to
"scripts": { "test": "node $NODE_DEBUG_OPTION node_modules/.bin/ava ..." }Otherwise it just runs the tests and doesn't break at my breakpoints.
Furthermore, I now have to remove any explicit --debug-brk or --inspect-brk in the "Edit configurations" dialog or things just get stuck. The $NODE_DEBUG_OPTION environment var is populated by WebStorm to --debug-brk=[port] --expose_debug_as=v8debug on older Nodes and --inspect-brk=[port] on later versions.
So I have two ways to proceed, but neither is ideal. I can debug with Node.js but then I have to duplicate AVA arguments from my package.json into the run configuration in WS, or otherwise I can debug with NPM but then I have to add WS-specifics to my package.json (and roundabout way of pointing at node_modules/.bin/ava).
I'm not sure if this is something that should be addressed by JetBrains or AVA (or at all) but figured I'd report here first due to the advertised recipe.
Environment
node.js v9.8.0
npm 5.6.0
darwin 17.5.0
ava 0.25.0 (but tried also 1.0.0-beta4 with same results)
From reading earlier discussion I thought I might ping @develar -- hope that's not too presumptuous of me.
I can debug with Node.js but then I have to duplicate AVA arguments from my package.json into the run configuration in WS
Is there any reason you can't configure AVA in the package.json file itself, rather than by passing arguments to the ava invocation?
I don't use WebStorm so I don't fully understand the options you're laying out here, but if you find a satisfactory approach we'd greatly appreciate any improvements to the recipe.
Thanks for the quick follow-up!
Yes, I would prefer to keep AVA config in package.json, and only there. And, conversely, I would prefer to not have any WebStorm-specific stuff in my package.json.
But the way I understand things currently, I can either follow the "Setup using Node.js" section in the recipe, which doesn't use NPM (and thus doesn't look at package.json, requiring me to duplicate AVA config in my IDE), or otherwise I can follow the "Setup using NPM" section in the recipe which appears is not applicable for latest WS -- and to make it work I have to add IDE-specific stuff to package.json.
Perhaps there is no better way to do this, but this situation isn't ideal. If I'm missing something obvious that'd be great. Either way, I think the recipe could be improved (slightly or significantly, depending on what I find out).
I guess I'll wait to see if any WebStorm expert chimes in here, and take it from there? As mentioned, there isn't much urgency for me: I can continue developing just fine, it's just not very pretty as it is now.
But the way I understand things currently, I can either follow the "Setup using Node.js" section in the recipe, which doesn't use NPM (and thus doesn't look at package.json, requiring me to duplicate AVA config in my IDE)
It sounds like you have config like "test": "ava --serial tests-from-here/ and-also-here/"? You should move those into a top-level "ava" object in the package.json.
I will try that but expect it won’t make a difference — I don’t think webstorm even looks at package.json at all in this “run/debug with node” mode, as opposed to the npm alternative? I would prefer to use the npm variant and keep everything neatly in package.json but as far as I can tell that requires me to use a pretty ugly way of invoking AVA (with a WS specific environment variable).
All right, thanks for the suggestion! I've tried with all AVA config in toplevel object in package.json, but it makes no difference unfortunately.
I don’t think webstorm even looks at package.json at all in this “run/debug with node” mode, as opposed to the npm alternative?
Either should just be an invocation of ava, which itself then looks at the package.json#ava field for its options.
which itself then looks at the package.json#ava field for its options.
Ah! I see, hadn't thought that far ahead, thanks for clearing that up. Perhaps I should have been more explicit though in my original post here, the issue isn't that it doesn't run AVA -- it does -- but that it doesn't break at my breakpoints unless I change
"scripts": { "test": "ava" }To
"scripts": { "test": "node $NODE_DEBUG_OPTION node_modules/.bin/ava" }This works but it's ugly, imho. But given that AVA itself inspects the package.json I suppose I could try to somehow hide this ugly $NODE_DEBUG_OPTION somewhere in the AVA config, assuming I can affect the execArgv that spawned processes get?
But given that AVA itself inspects the package.json I suppose I could try to somehow hide this ugly $NODE_DEBUG_OPTION somewhere in the AVA config, assuming I can affect the execArgv that spawned processes get?
That's not customizable.
We do have logic (contributed by @develar) that forwards appropriate --inspect flags though. Perhaps ava $NODE_DEBUG_OPTION will work?
Thanks again for your quick reply @novemberborn.
It has to be node $NODE_DEBUG_OPTION ava, or at least according to my experiments thus far.
I did notice the logic you mention, was actually thinking of making a PR on top of that to merge in stuff from this env var if present. But I hesitate, on the one hand because I don't really grok all that is going on there (or more accurately I would have thought it should work differently than what I see there).
And on the other hand it'd be addressing this issue for ava specifically when actually it affects every npm script I might want to debug from WebStorm. I am currently thinking about patching my npm-cli locally to merge $NODE_DEBUG_OPTION into execArgv when spawning subprocesses.
It has to be node $NODE_DEBUG_OPTION ava, or at least according to my experiments thus far.
Ah yes, sorry. This code still reads from execArgv which is the arguments for node itself. #1505 covers AVA itself supporting --inspect.
Yeah, so I guess the point there is that some of the proces.argv of the main ava thread should be mapped to execArgv of the workers.
Regarding WebStorm I’m inclined to give up — they apparently make a point of fixing their own debug port and make it available via that $NODE_DEBUG_OPTION. Which might be well and good but I don’t see a pretty way of injecting that in the “Debug via NPM” variant in the recipe.
I found two methods but both have to be done separately for each package script I might wish to debug (the one I mentioned earlier which is to insert the env var into package.json and another which hacks the shebang line in .bin/ava.
I think the other issue you linked won’t (can’t) help with having to figure out which port WS picked for a given run.
Regarding WebStorm I’m inclined to give up — they apparently make a point of fixing their own debug port and make it available via that $NODE_DEBUG_OPTION. Which might be well and good but I don’t see a pretty way of injecting that in the “Debug via NPM” variant in the recipe.
It doesn't need to be pretty. We just need to explain how to make it work. Would you be interested in updating the recipe?
I found two methods but both have to be done separately for each package script I might wish to debug (the one I mentioned earlier which is to insert the env var into package.json and another which hacks the shebang line in .bin/ava.
Let's not hack the .bin/ava stub.
I think the other issue you linked won’t (can’t) help with having to figure out which port WS picked for a given run.
The way I understand it #1505 could make AVA recognize Node.js' --inspect arguments and map / forward the debug protocol to the workers. That should work nicely with WS.
I’ll give updating the recipe a try, sure. The debug port forwarding is not going to work — if I understand things properly. But maybe I don’t :-)
The debug port forwarding is not going to work — if I understand things properly. But maybe I don’t :-)
node $NODE_DEBUG_OPTION node_modules/.bin/ava should work. Oh, perhaps try node $NODE_DEBUG_OPTION -r 'ava/cli', too.
Everything else requires code changes in AVA, which are tracked in #1505.
Any progress?
Sorry, this completely fell off my radar, and I am swamped for the time being. If this isn’t actually appearing to bother many, perhaps simply close the issue?
Sorry, this completely fell off my radar, and I am swamped for the time being. If this isn’t actually appearing to bother many, perhaps simply close the issue?
@erikkemperman that's fine. We'd still like to improve our documentation, but don't feel that it's on you 😄
Any progress?
@stavalfi it's safe to assume that if an issue is still open, there has been no progress. You could have a look at the release notes since the last comment on the issue thread to be sure.
@novemberborn thanks, I will do that.
If this isn’t actually appearing to bother many, perhaps simply close the issue?
@erikkemperman it's a bug. Don't close this issue, even when only a single person suffers from it.
I'm interested in working on this and have WebStorm. Any idea if this is still an issue? Sample code to try with? (new to contributing so sorry if these are covered elsewhere)
@cameronts I suppose try writing and debugging a test with WebStorm, following our documentation. If it works, then we can close this. And otherwise you could do a PR with improvements to the docs.
@cameronts I suppose try writing and debugging a test with WebStorm, following our documentation. If it works, then we can close this. And otherwise you could do a PR with improvements to the docs.
Thanks will do
@erikkemperman I'm trying to reproduce, have my project set up but.. wondering if you still have your old webStorm project files for this issue. Would save some time..