Roadmap for a 3.0

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