firsttris / vscode-jest-runner

Simple way to run or debug one or more tests from context menu, codelens or command plalette
https://marketplace.visualstudio.com/items?itemName=firsttris.vscode-jest-runner
MIT License
265 stars 124 forks source link

Possible Debug bugs/improvements --inspect-brk=3302' to --inspect=33027 #166

Closed PizzaPartyInc closed 2 years ago

PizzaPartyInc commented 3 years ago

Hey!

I've been having hard time debugging tests recently (v0.4.34) and noticed 2 places where the experience can be improved:

  1. When you click the codelens for debugging - debugger is attached successfully (blue VSCode status bar becomes orange) and test proceeds to being debugged. But when it finishes and you click 'Up arrow' keyboard key while terminal is in focus to bring up the script that was executed last and try to relaunch debugging - debugger no longer attached - VScode status bar stays blue and terminal waits on the lines like:
    Debugger listening on ws://127.0.0.1:33027/b9a608dd-232c-4479-a9fd-0dc4eb773d78
    For help, see: https://nodejs.org/en/docs/inspector

What changed this behavior is manualy changing '--inspect-brk=33027' to '--inspect=33027'. Then re-launchin script successfully attaches the debugger. (but I would not do this every time)

Question/Suggestion - is there a way to configure the inspect flag? And if not - is it possible to implement such configuration?

  1. There is currently an option to define jestrunner.jestCommand, but it's only applicable when using Run, and not when using Debug. In my case, the value is something like yarn util:load-vars jest. In the context of monorepo, we separate configuration in root configuration and service configuration and util:load-vars loads all environment variables. Since some of the tests use those variables, we basically need to prefix all scripts that need variables with yarn util:load-vars. Is there some option that would allow doing so for Debug option, and not just Run? And if not - is it possible to implement? :)

For example, I was currently able to debug by manually changing a debug script from this:

e:; cd 'e:\path_to_monorepo_service'; & 'C:\Program Files\nodejs\node.exe' '--inspect-brk=25326' 'node_modules\jest\bin\jest.js' 'e:/path_to_monorepo_service/path_to_test_file.spec.ts' '-c' 'e:/path_to_jest_config/jest.config.js' '-t' 'Test Finder string' '--runInBand'

to this:

e:; cd 'e:\path_to_monorepo_service'; & yarn util:load-vars 'C:\Program Files\nodejs\node.exe' '--inspect=25326' 'node_modules\jest\bin\jest.js' 'e:/path_to_monorepo_service/path_to_test_file.spec.ts' '-c' 'e:/path_to_jest_config/jest.config.js' '-t' 'Test Finder string' '--runInBand'

Thanks! :)

firsttris commented 3 years ago

hey @PizzaPartyInc

i don't this i can change the --inspect-brk flag i think it will be added by vscode

here is the corresponding source code, where we create the debug config.

https://github.com/firsttris/vscode-jest-runner/blob/84d7f8f04d898b7d291c8144a0e0700e80ccf1a4/src/jestRunner.ts#L132

firsttris commented 3 years ago

If you know how to improve it, pull-requests and suggestions are always welcome ;)

PizzaPartyInc commented 3 years ago

Hey! Thanks for the reply! Unfortunately, I don't see myself having free time in the near future to explore how vscode extensions are made and work, my knowledge is close to zero here...

The inspect flag is a QoL improvement, and for additional prefix for debugging, I'm currently loading configs 2 times from the code as a workaround. It's not pretty, but it works....

So, pull requests would have to wait. As for suggestions - the straightforward way would be to add a separate config value, e.g. jestRunner.debugCommand and have a value like yarn util:load-vars 'C:\Program Files\nodejs\node.exe' '--inspect' 'node_modules\jest\bin\jest.js' for it but the way it looks it would not be realistic to implement since a lot of debugging script generation logic is happening in vscode components. I would check vscode.DebugConfiguration to see if there is some fitting option that can help there, but I can't quickly find the source code for that type, so hard to tell.