Closed hfournier closed 7 months ago
I encountered the same problem and found #76. Is this related?
@Benjamin-Frost It may be related, but certainly not resolved. Unfortunately, it doesn't look like anyone's looked at this yet.
I can also reproduce this.
OS: Windows 11
Node Version: v20.9.0
Package Version: @clack/prompts
v0.7.0
Reverting #104 can fix this on Windows 11. I cannot replicate #103 on Windows, will try to test it on Mac later.
Update: Reverting #104 will break #103. No luck.
The stop command that seems to be blocking it, without it, the input works just fine. It feels like with the Stop command, there's a readline command blocking the execution of clack
It seems to be related to an ancient note/tty bug https://github.com/nodejs/node/issues/38663 On my tests, keypress events wont trigger when you type on the terminal, but during this problem, if you inject code on the node stdin stream, keypress will be triggered.
process.stdin.push(`\r`); //Enter Key
readline.emitKeypressEvents(process.stdin);
It seems like a native layer locks the console to itself and only releases it after reading a line
I am on macos and just testing clack. Keyboard input not working at all on the base example.
zshell
Environment
Describe the bug After updating to the latest version, prompt behavior has changed after awaiting spinner. The await line between spinner start and stop is causing issues with the second following prompt, where it does not respond to any key input (like arrow keys or even Ctrl-C), only the [Enter] key, which then "activates" the normal behavior, but creates a duplicate of the first option. With the await line commented out, everything works as expected. The prompt order does not matter, the second one is always effected.
To Reproduce
Steps to reproduce the behavior:
Using the following code:
Expected behavior To be able to navigate from prompt to prompt using the keyboard, and use Ctrl-C to quit.