Just a heads up I am experiencing the following on WIndows 8.1 SBoudrias/Inquirer.js#266
node -v 4.0.0
cc @kentcdodds
Hmmm. That's annoying :-( I guess you'll just have to hand-craft your commits until that bug gets fixed...
I followed the rabbit hole and found nodejs/node#2996
Interesting. Thanks for finding that. Is this something we should add to docs until it gets resolved?
Seems like a good idea to me. I'm thinking about adding it to my contributing docs... Even better: detect the node version and os and give a warning if this could be a problem.
Quick update. Looks like the node issue is still open and they're trying to figure out a fix that doesn't introduce a regression. Until then, we wait. :)
Update: It looks like the change that started causing this issue has been reverted so I'd imagine it is available in nightlies: https://github.com/nodejs/node/commit/af46112828cb28223050597f06b5e45a659e99d6
But I'm not sure when it will get released and perhaps more importantly when it will get back ported to Node 4 LTS.
Quick update: This will be released in the next Node.js versions on both the 4.x and 5.x branches. I'm going to close the issue for now since it is merged and out of the control of this repo.
More info:
https://github.com/eslint/eslint/issues/3880
I just had the problem on windows, it still doesn't work with the last 4.x version (4.2.2), but it works with the last 5.x version (5.1.0), so that's all good :)
Thanks for the confirmation @ocombe. I know there are some security patches being worked into older versions so perhaps it is taking a bit longer to get this in to those. At any rate, it is good to know it is fixed in 5.x!!!
I also met this .How do you solve this problem? @BarryThePenguin
@clearbug see https://github.com/nodejs/node/issues/5384. Now it's a new problem.
I re-opened this since as @egoroof stated, this continues to be a node or windows issue. Latest update from https://github.com/nodejs/node/issues/5384 is that it might be an issue with windows itself. Basically it is tricky to fix because it presents as a race condition.
Commitizen is essential to my dev workflow, so I made a quick hack so I could just type out the feature (rather than use arrow keys).
This gets the job done, but i hope the nodejs guys get this sorted out.
simonwjackson/cz-conventional-changelog@c408892e6fda003f70fdcadcd17c277a75b7d82c
Looks like there's another potential fix coming through libuv/libuv#852, nodejs/node#6796
Both are closed.
I experience the same on Windows 7 using the git bash from the latest Git install (mintty 2.7.3 x86_64-pc-msys). It works fine in windows cmd.
Seeing this on Windows 10 as well (mintty 2.7.7 x86_64-pc-msys)
Having this issue, too. CMD and GIT BASH both deny the arrow movement
window cmd can work, but git bash mintty not

Workaround
In my Git Bash keypresses are actually executed invisibly, they just don't cause a rendering refresh. So e.g. for a refactor, after git cz i press down arrow 4 times and hit enter, and it shows refactor as type of change.
(Windows 10 Version 1803, mintty 2.8.5, git bash 2.8.0 - try installing the latest version of git bash)
Found this after a lot of research subtly hidden here, comment from March 3 2018:
https://github.com/terkelg/prompts/pull/36
Workaround - use yarn instead of npm
in case it helps: - I have similar issue
on my Windows 10 Pro box, git bash terminal
If I use:
npm run commit
then the arrow keys do not work.
BUT if I instead use yarn:
yarn run commit
then the arrow keys DO work, and I can successfully select a change type.
related: previously, when arrows were broken, I was typing in 'docs' or 'refactor'
Most helpful comment
Having this issue, too. CMD and GIT BASH both deny the arrow movement