Feat (password): add option to toggle password visibility

[matteosacchetto]

Implementation of the feature request idea #1330

Steps:

• Add basic functionality to skip the transform function
• Add option to show or hide the password
• Add tests
• Add documentation
• Decide the shortcut to use
• Decide how to manage the UX

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (11bbb4b) 94.48% compared to head (ae62463) 94.54%.
Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1334      +/-   ##
==========================================
+ Coverage   94.48%   94.54%   +0.06%     
==========================================
  Files          51       51              
  Lines        4457     4476      +19     
  Branches      775      780       +5     
==========================================
+ Hits         4211     4232      +21     
+ Misses        241      239       -2     
  Partials        5        5              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[matteosacchetto]

I started implementing the feature request of #1330
I still have to add tests, and handle the UX

Moreover, we also need to decide how we should call the new options

[matteosacchetto]

@SBoudrias is there a way to test keyboard combinations, like CTRL + space?

[SBoudrias]

is there a way to test keyboard combinations, like CTRL + space?

Not at the moment, we should definitively add it to the testing library though!

[matteosacchetto]

is there a way to test keyboard combinations, like CTRL + space?

Not at the moment, we should definitively add it to the testing library though!

I will look into this further, since I think is not that difficult to add to the library, and it would allow us to write tests for this new feature

[matteosacchetto]

is there a way to test keyboard combinations, like CTRL + space?

Not at the moment, we should definitively add it to the testing library though!

I will look into this further, since I think is not that difficult to add to the library, and it would allow us to write tests for this new feature

Quick update: to allow for testing keyboard combinations is relatively easy to implement. We just need to add to @inquirer/testing an additional event, which exposes all the parameters a 'keypress' event supports

export interface Key {
  name?: string | undefined;
  ctrl?: boolean | undefined;
  meta?: boolean | undefined;
  shift?: boolean | undefined;
}

We just need to decide whether to implement a new function, modify the current keypress without a breaking change or modify it with a breaking change.
I would say it would be better to implement a new function or to modify the keypress function without introducing a breaking change, since the option of passing keyboard combinations/shortcuts is less used than passing normal key presses

[SBoudrias]

I think there's a small logic mistake here. When the prompt is completed, we shouldn't show the password in plain text.

[matteosacchetto]

When the prompt is completed, status will be equal to 'done', so the if at line 90 will be false, and formattedValue will remain equal to the transformed value. In the tests, I explicitly check for this scenario, in order to avoid password to be shown in plain text after the prompt is completed.

[SBoudrias]

Sooo, did some more digging into this. And it turned out to be a bit of a headache.

Depending on the environment and the terminal used, there can be a lot of conflict.

For one, CTRL + Space for me open the AI helper sidebar and never reach the node program.

I then started to think of keys; like CTRL+H, but that's a backspace shortcut (and it doesn't even register as the H key.)

So long story short:

1. I added node tools/keys.mjs to the repo latest version to play with.
2. Potential solution 1: finding a key combo that'll reasonably work for most environment (terminals, OS & consider non-english keyboards).
3. Have a basic OS switch and use keys per OS that are reasonably going to work.

[matteosacchetto]

Separating the rewrite from the new feature was the right choice!

I'm still experimenting with ideas on how to implement this feature but I have not yet found something which works consistently between different terminals

I think that if we want to ship this feature, in the end we need to find a shortcut which works on most of them and accept that in some environments it won't work as expected

If only there was a way to get which keyboard shortcuts are available in a give environment...