Roadmap for a 3.0

[joeykilpatrick]

When comparing this package and its alternatives, I think this one has the most potential for releasing some much-needed features for this space. I wrote a small analysis of comparable packages on my personal blog.

Here's what I think this package and some of its alternatives are lacking and what could be accomplished in a 3.0 release:

1. Strong types - This package has much better types than inquirer or enquirer through DefinitelyTyped, but I think what is really needed is a package with an interface that is designed with strong type inference in mind.
2. Extensibility - The vast majority of the GitHub issues for this repo are requests to add support for niche customization options for different prompt types. To solve this, an extensible and fully-customizable interface could be provided using the approach that enquirer added that allows users to customize provided prompt types by creating subclasses of them and overriding their base properties and methods. Unfortunately, enquirer never added strong typing for this feature, making it difficult to use. Additionally, users could publish their own subclasses of common prompts that extend this package, similar to the model that inquirer uses for its plugins.
3. Support for testing - This package lets users "inject" values for prompts to help users write their own tests, but this approach is brittle and makes it hard to test things like users pressing CTRL+C. I think a new testing strategy is needed, both for unit tests in this repo and for users to test their own custom prompts. Perhaps an easy way to mock readline or something.
4. Release as an ESM module - This may be more controversial, but other packages (e.g. chalk) are beginning to only be released as an ESM module. You can find some of the reasoning here. I think this package should follow suit. There are multiple advantages and there is no reasonable use-case for this package where support for CommonJS would be required.
5. Automated deployment to npm - This is important for reliability and security.
6. Full unit-testing and code coverage - Today, it's difficult to raise a PR and make sure that you don't introduce new bugs or change how a prompt is displayed. Full unit-testing would make sure that unintended changes are caught before publishing.

Since we don't have full code coverage today, it is going to be very difficult to make sure that these changes will be fully compatible with the current Prompts 2.x.x version. I think releasing these changes as part of a 3.0 would be the best option.

I am more than happy to submit PRs for these features. For the more complicated ones (like #⁠1 and #⁠2), perhaps GitHub Discussions could be enabled to flesh out what the interfaces would look like before any implementation begins.

@terkelg

[posva]

This would be great! It would help if you also have the publish rights to npm 😄

What do you think about fixing some low hanging fruits before releasing v3? Adding the types (https://github.com/terkelg/prompts/pull/396) and some other small bugs about not correctly handling combinations of keys seems to be simple enough to fix and localized enough (in the source code) not to have too much of an impact. Personally, I would also like to see some like this fixed 👀. The package doesn't seem to have tests for the different actions at the moment though

[ctsstc]

Meanwhile I'm over here looking for something that isn't an esm module since it's causing too much friction currently unfortunately, so this is what I landed on and I'm happy for that. Hopefully in the near future this is no longer the case though.

Upon my first usage of this utilizing a confirmation prompt, it would be great to have better typing, like if it could expose the name as a key, or remove that in general and standardize it, as well as then in that scenario it should be expected that it returns a boolean type.

[equiman]

+1 for Support Testing 🙏

[danielbayley]

…other packages (e.g. chalk) …

I would also like to see kleur replaced with chalk as a dependency, which has a nicer syntax.

[Jolg42]

@danielbayley from experience (see https://github.com/prisma/prisma/pull/18900) I prefer kleur as it's smaller.