-
-
Notifications
You must be signed in to change notification settings - Fork 303
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Roadmap for a 3.0 #393
Comments
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? |
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. |
+1 for Support Testing 🙏 |
I would also like to see |
@danielbayley from experience (see prisma/prisma#18900) I prefer |
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:
inquirer
orenquirer
through DefinitelyTyped, but I think what is really needed is a package with an interface that is designed with strong type inference in mind.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 thatinquirer
uses for its plugins.readline
or something.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.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
The text was updated successfully, but these errors were encountered: