Open samreid opened 3 years ago
Here are my main concerns before starting on this:
Would it help if we use util.promisify
as described in https://nodejs.org/api/child_process.html#child_process_child_process_exec_command_options_callback ?
@jonathanolson or @zepumph can you please advise? Or let me know if we should request other volunteers at dev meeting.
Is it ok for perennial clients to have to pass in a winston option for every execute?
That seems less than ideal, preference against that. Could we add winston to chipper?
The other consistency sounds good to me. My main question is... would ExecuteResult
extend Error
? I see it either as "we are throwing something that isn't an error" or "we are returning something normal that is subtyped as an Error". Thoughts?
Is it OK to put execute in dual/?
How possible is it to instead devote our energy into converting all our tooling to modules? Perhaps that isn't worth it because of the soon-to-come (???) typescript conversion. No matter, this feels more and more like a headache in the making.
How possible is it to instead devote our energy into converting all our tooling to modules?
Can you please elaborate on how converting tooling to modules would help? execute
is already a module and suffers from the "perennial always wants to be in master" problem.
Oh, a simple answer: because I was being dump and incorrect. Do you want to go all in on dual/
as our strategy to use files in perennial and chipper. I would really like to.
I added winston to chipper and moved execute to dual as part of https://github.com/phetsims/chipper/issues/1018. Next steps:
message
new ExecuteResult
.message
My main question is... would ExecuteResult extend Error? I see it either as "we are throwing something that isn't an error" or "we are returning something normal that is subtyped as an Error".
I don't think ExecuteResult should extend Error--that sounds confusing for the normal non-error case. Maybe ExecuteError can extend Error and contain ExecuteResult? But maybe that would be an awkward API.
Numerous occurrences rely on the success output just resolving with stdout
. Do we want to change all of them to resolve with the ExecuteResult
and they can take the stdout
? Or do we like the convenience of resolving with stdout
even though sometimes in resolves with ExecuteResult
? For instance, getBranch currently reads:
return execute( 'git', [ 'symbolic-ref', '-q', 'HEAD' ], `../${repo}` ).then( stdout => stdout.trim().replace( 'refs/heads/', '' ) );
But if we resolve with ExecuteResult
it would be more like:
return execute( 'git', [ 'symbolic-ref', '-q', 'HEAD' ], `../${repo}` ).then( result => result.stdout.trim().replace( 'refs/heads/', '' ) );
@jonathanolson can you please advise?
Do we want to change all of them to resolve with the ExecuteResult and they can take the stdout?
That seems fine/expected to me.
I got partway through in this patch:
However, I cannot proceed confidently because there are too many occurrences that I have no familiarity with. For instance, there are 22 files with return execute(
and all of these usage cases must be traced back to make sure return values and thrown errors are handled with the correct types. I would feel better if someone familiar with that side could take the lead or pair program during these changes. Checking many of these files, it seems @jonathanolson is the responsible developer. @jonathanolson can you please recommend how to proceed?
From https://github.com/phetsims/perennial/issues/206#issuecomment-793031078,
I recommend the following changes for execute.js.
message
new ExecuteResult
.message
Note that we raised reasons not to put files in dual/ which are under discussion in https://github.com/phetsims/phet-io/issues/1733#issuecomment-877301298