Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix #342 set child process debug port to available #613

Closed
wants to merge 1 commit into from

Conversation

develar
Copy link
Contributor

@develar develar commented Mar 7, 2016

We decided to support AVA debug (#342) without any efforts on your side.

But:

Unfortunately, although idea of fix is very simple (getPort().then), change is complex because existing code adds custom context-dependent methods to Promise. And Github diff view is very unclear compared to IntelliJ IDEA.

What's done:

  • if debug-brk= or debug= in the main process args, find available port and change debug arg.
  • fork now returns object with custom methods (on, run) and promise field. We don't add custom methods to promise anymore.
    • to simplify test code (and reduce changes), method then added to returned object. Test-only — in production we use promise field.
    • send is not used, as far I see, but I didn't delete it. Should I do it?

Please note — as it stated in my comment, debugging will be still not possible due to another issues. Solving sourcemap issue is out of this PR scope.

PS: AVA is so awesome, that multi-process debug was reimplemented in the IntelliJ JS Debugger to avoid multiple debug tabs (IntelliJ Platform 146+).

@sindresorhus
Copy link
Member

Tip for reviewing this, append ?w=1 to the diff URL to ignore whitespace changes: https://github.com/sindresorhus/ava/pull/613/files?w=1

@@ -18,6 +18,7 @@ var AvaError = require('./lib/ava-error');
var fork = require('./lib/fork');
var formatter = require('./lib/enhance-assert').formatter();
var CachingPrecompiler = require('./lib/caching-precompiler');
var getPort = require('get-port');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be placed above the relative requires (on line 17).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

@sindresorhus
Copy link
Member

Nice! Thanks for working on this @develar :)

@sindresorhus
Copy link
Member

Can you add some tests?

@sindresorhus
Copy link
Member

fork now returns object with custom methods (on, run) and promise field. We don't add custom methods to promise anymore.

What's the benefit of this?

@develar
Copy link
Contributor Author

develar commented Mar 7, 2016

fork now returns object with custom methods (on, run) and promise field. We don't add custom methods to promise anymore.

What's the benefit of this?

My first approach was just add getPort().then And then I realized, that existing code doesn't work with nested promise — .on is not a function. But we cannot return promise from fork directly until promise of getPort() is not resolved — so, we return nested promise.

@novemberborn
Copy link
Member

send is not used, as far I see, but I didn't delete it. Should I do it?

It's used as of a few hours ago 😜 https://github.com/sindresorhus/ava/blob/1868204c1901f45b4f66a520ef6486fdd71fe1d2/api.js#L210

tests[index] = forkManager;
forkManager.on('stats', tryRun);
})
.catch(function (error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is asynchronous whereas onForkStarting is not. Probably best to build up tests similarly (and synchronously) to how it was done before and leave the rest of the code as it is. (Note that I just changed this you so you'll need to rebase).

@jamestalmage
Copy link
Contributor

And then I realized, that existing code doesn't work with nested promise — .on is not a function.

You might be able to solve this with promise-delegates.

@novemberborn
Copy link
Member

Hey @develar, would be great to have debug support for IntelliJ. Will you have time to follow up on the feedback here?

@develar
Copy link
Contributor Author

develar commented Apr 5, 2016

@novemberborn Sorry for delay, it will be addressed this week.

@novemberborn
Copy link
Member

@develar no worries, that's great! 👍

@vadimdemedes
Copy link
Contributor

Closing due to lack of response from the author of PR.

@jamestalmage
Copy link
Contributor

@develar - If you ever get around to updating this PR, we would still be interested in merging. However, be aware, there is work happening towards official Node debugger support: nodejs/node#2546 (comment).

@develar
Copy link
Contributor Author

develar commented May 25, 2016

New PR — #874.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants