-
Notifications
You must be signed in to change notification settings - Fork 154
Bi directional communication #100
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -132,16 +132,8 @@ export default (store: any) => (next: any) => (action: any) => { | |
additionalArgs.push('--', '--coverage'); | ||
} | ||
|
||
/* Bypasses 'Are you sure?' check when ejecting CRA | ||
* | ||
* TODO: add windows support | ||
*/ | ||
const command = | ||
project.type === 'create-react-app' && name === 'eject' | ||
? 'echo yes | npm' | ||
: 'npm'; | ||
const child = childProcess.spawn( | ||
command, | ||
'npm', | ||
['run', name, ...additionalArgs], | ||
{ | ||
cwd: projectPath, | ||
|
@@ -158,6 +150,20 @@ export default (store: any) => (next: any) => (action: any) => { | |
next(attachTaskMetadata(task, child.pid)); | ||
|
||
child.stdout.on('data', data => { | ||
// The 'eject' task prompts the user, to ask if they're sure. | ||
// We can bypass this prompt, as our UI already has an alert that | ||
// confirms this action. | ||
// TODO: Eject deserves its own Redux action, to avoid cluttering up | ||
// this generic "RUN_TASK" action. | ||
// TODO: Is there a way to "future-proof" this, in case the CRA | ||
// confirmation copy changes? | ||
const isEjectPrompt = data | ||
.toString() | ||
.includes('Are you sure you want to eject? This action is permanent'); | ||
|
||
if (isEjectPrompt) { | ||
sendCommandToProcess(child, 'y'); | ||
} | ||
next(receiveDataFromTaskExecution(task, data.toString())); | ||
}); | ||
|
||
|
@@ -270,3 +276,9 @@ const getDevServerCommand = ( | |
throw new Error('Unrecognized project type: ' + projectType); | ||
} | ||
}; | ||
|
||
const sendCommandToProcess = (child: any, command: string) => { | ||
// Commands have to be suffixed with '\n' to signal that the command is | ||
// ready to be sent. Same as a regular command + hitting the enter key. | ||
child.stdin.write(`${command}\n`); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @superhawk610 At the moment, I'm merging windows-support & npm-to-yarn branch (not pushed yet) and there I've noticed that ejecting is not working with-out error message and it seems that it is happening at line 283. The error message is like in this issue. Telling that the socket is already closed. Not exactly sure what happens here but it could be related that we're not sending Sending I'll try to eject at Bennys windows-support branch so I know if it was working there. Maybe this could also be related to my setup: The app is ejected afterwards but there is this error message in console. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK, not sure what it was but after removing |
||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I checked
react-scripts
's eject code and seems like the prompted question is hard-coded and there is not any parameters for passing prompts (something like--force
or--yestoall
). I don't think it is something to change by its own. If there is going to be a change I think it would effect multiple places so I don't think we should worry about it for now.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The discussion about Next.js support in #59, as well as this issue of future-proofing, makes me think it may be worthwhile to extract each framework's specific interactions into some sort of plugin file that would abstract CLI interactions into a consistent and predictable style - here's a very loose idea of what the structure might look like:
I imagine each plugin would have a
create
block and then could optionally have any number of framework-specific blocks as well, maybe exported as an array so they could be iterated over by the UI without any knowledge of how many there are in total?Additionally, the
CMD_
functions could all be piped through @bennygenel'sformatCommandForPlatform
.This is clearly far too much boilerplate to be justified for just CRA and Gatsby, but as the project grows it has the marked benefit of placing all the CLI interaction logic in an easy-to-find (and thus easy to maintain) location and adds a further degree of separation between UI and business logic.