Studio: Refactor Studio to depend on the CLI for starting sites #2172
Conversation
bcotrim
force-pushed
the
stu-1019-studio-refactor-studio-to-depend-on-the-cli-for-starting
branch
from
034011f to
e882445
Compare
bcotrim
force-pushed
the
stu-1019-studio-refactor-studio-to-depend-on-the-cli-for-starting
branch
from
e882445 to
d0e4359
Compare
fredrikekelund
left a comment
fredrikekelund
left a comment
There was a problem hiding this comment.
Great work, @bcotrim! 👍 Very satisfying to see this come together. It's working nicely in my testing so far.
I left a couple of smaller comments.
I'd also be interested to hear your perspective of this site list --watch approach vs watching the config file for changes and using some mechanism (a version of the studio site status command, perhaps) to check the site status when latestCliPid changes. I don't really have a strong opinion there, but it would be good to have a documented reason for going one way or the other.
cli/commands/site/list.ts
Outdated
| choices: [ 'table', 'json' ], | ||
| default: 'table', | ||
| description: __( 'Output format' ), | ||
| } ) | ||
| .option( 'watch', { | ||
| type: 'boolean', | ||
| default: false, | ||
| description: __( 'Watch for site status changes and update the list in real-time' ), | ||
| } ); | ||
| }, | ||
| handler: async ( argv ) => { | ||
| try { | ||
| await runCommand( argv.format as 'table' | 'json' ); | ||
| await runCommand( argv.format as 'table' | 'json', argv.watch as boolean ); |
There was a problem hiding this comment.
choices: [ 'table', 'json' ] as const,
default: 'table' as const,
description: __( 'Output format' ),
} )
.option( 'watch', {
type: 'boolean',
default: false,
description: __( 'Watch for site status changes and update the list in real-time' ),
} );
},
handler: async ( argv ) => {
try {
await runCommand( argv.format, argv.watch );Kind of a nitpick, but that's how we get yargs to provide the correct types for the options.
| } ); | ||
|
|
||
| app.on( 'quit', () => { | ||
| void stopAllServersOnQuit(); |
There was a problem hiding this comment.
This will kill all running processes, regardless of whether they were started from the CLI or from the app. We could just accept this behavior, but @nightnei also had a pretty good idea to display a simple modal before quitting the app that says "Do you want to stop the running sites? Yes / Leave them runing"
There was a problem hiding this comment.
I like that idea! I would add a "remember my decision" checkbox. I think that provides enough tools for our users to adjust their experience as it work best for them. We can always revisit in the future.
Should I handle that change in this PR or as part of STU-1078 ?
| // CLI-managed sites don't have PHP instance, return cached theme details for Now | ||
| // ToDo: Implement logic to fetch theme details using mu-plugin? | ||
| if ( ! server.server.php ) { | ||
| return server.details.themeDetails; | ||
| } |
There was a problem hiding this comment.
Once we have WP-CLI support, we might also consider using the wp eval command
| export function executeCliCommand( | ||
| args: string[], | ||
| options: ExecuteCliCommandOptions = {} | ||
| ): CliCommandEventEmitter { |
There was a problem hiding this comment.
| ): CliCommandEventEmitter { | |
| ): [CliCommandEventEmitter, ChildProcess] { |
Optional, but we could return the child process instance from this function, too. It would save us from the dance of having to set the kill function on the EventEmitter
bcotrim
force-pushed
the
stu-1019-studio-refactor-studio-to-depend-on-the-cli-for-starting
branch
from
5a0ae52 to
dd0994d
Compare
Related issues
Proposed Changes
--watchtostudio site listcreateCliServerProcessso Studio can start and stop sites using Studio CLITesting Instructions
npm installnpm startstudio site listreturns the correct status for the sitePre-merge Checklist