Switch from `enquirer` to `clack`?

[hyperz111]

enquirer is NOT maintained for 2 years. So i prefer to replace it with clack. But now clack is in alpha phase. If clack is stable (v1), maybe we can switch to it.

[hyperz111]

What do you think @JoshuaKGoldberg?

[lumirlumir]

From the context you suggested, I'm not currently convinced that migrating to clack would provide any clear benefit.

There was a similar issue before (#183), and per the comment there (#183 (comment)), we don't plan to replace a working package with another unless it offers a clear benefit.

For example, If we use the pre-styled @clack/prompts package, its size is 480 KB. By comparison, enquirer is only about half that, at 224 KB.

Also, the number of sub-dependencies is the same — four each.

From a performance perspective, these packages are command-line tools whose main purpose is to wait for user input and select a template based on it, so I'm not sure this would provide any performance benefit.

And if the main purpose of this change is to use the well-designed UI of @clack/prompts, I'm not sure it's worth swapping out the current package just for that.

Based on the context, I'm currently -1 on this change.

[hyperz111]

If we use the pre-styled @clack/prompts package, its size is 480 KB. By comparison, enquirer is only about half that, at 224 KB.

This is because @clack/prompts have so much components like spinner, log, box, and other.

[JoshuaKGoldberg]

I'm personally in favor of moving off of not-maintained libraries - and I use clack in my own projects. But setting that aside, I believe the ESLint viewpoint is to only migrate to a new library when there's a clear benefit to do so. Not being maintained in itself is not motivation to change in that viewpoint. It's only the downstream effects of a lack of maintenance that would be: long-standing bugs, security reports, etc. If you can state some concrete motivations to move that would be helpful for this issue.

This is because @clack/prompts have so much components like spinner, log, box, and other.

If ESLint's create-config doesn't use those components, then they're just dead weight in node_modules/. Just thinking out loud: it would be nice if Clack provided a way to explicitly opt into specific packages/parts as needed. That's an issue / feature request to be sent over to Clack, though.

What do you think @JoshuaKGoldberg?

Aside/curiosity: there's no need to ping me directly 🙂. I'm just one of the members of the ESLint committer team. If you file an issue on an ESLint repo then >=1 person from ESLint will respond to it generally within a week (or two, in slow seasons such as right now's holidays).