ux module to be removed in next major

[mdonnalley]

What's Happening

We are going to remove the ux module in the next major version of @oclif/core.

Why?

The ux module contains a mix of poorly-maintained, half-baked implementations of things like logging, table generators, spinners, progress bars, etc. Some of these are own implementations and some are just re-exports of existing libraries.

For us, the biggest benefit of removing ux is that it reduces the amount of functionality that we have to maintain. For the oclif community, there are two main benefits:

• Reduces the size of @oclif/core by removing some of the dependencies.
• Forces you to use dedicated libraries that are better supported and have more features.

What Do I Do?

You will need to replace everything that ux was doing with dedicated libraries. Here are a few suggestions:

• For prompts: inquirer
• For spinners: ora
• For progress bars: cli-progress
• For hyperlinks: terminal-link
• For tables: tty-table, cliui
• For trees: object-treeify
• For colored JSON: color-json
• For notifications: node-notifier
• For links: terminal-link
• For rendering react components: ink

[arthurfiorette]

One of the best things about oclif is the ux module, the way it works is incredible...

Couldn't the solution be to just export APIs that call these other libraries you mentioned? This way oclif keeps the uxfeature and doesn't need to manually implement these features, only "proxy" calls to other packages...

[mdonnalley]

Couldn't the solution be to just export APIs that call these other libraries you mentioned?

We're doing this in a couple places already (ux.progress and ux.tree) but we want to get away from it. A couple reasons:

1. It locks developers into using those libraries in the way we implemented them. We'd prefer for you to have the freedom to implement the exact user experience you want for your users.
2. It bloats the package size. As a developer you might only want to use a few methods on ux - in that case you don't need all those other packages. So it's better to allow developers to pick and choose the exact library they want to use.

I understand that it's easier to have everything you could possibly need inside a single module since you don't have to think about which library will work for you, etc. But I truly believe that this is a better solution for everyone in the long term.

[arthurfiorette]

#999 (reply in thread)

[mdonnalley]

Closing this since v4 has now been released: https://github.com/oclif/core/releases/tag/4.0.0

[naderghanbari]

Is it too late to put the ux module in a different package (oclif/ux), freeze it and keep it for a while. That would leave ample transition time, or perhaps the community can keep maintaining it (and get at the valid concerns/challenges you mentioned). #day-dreaming

I am on v3 of the core, and I have to do a non-trivial refactor of a huge code surface to upgrade to v4, and I agree with @arthurfiorette , once of the jaw-dropping features of oclif has been the ux module for our team.

[mdonnalley]

You (or anyone) is welcome to fork v3 and pull out any of the code that you need. But we have no plans of creating a separate package ourselves.

Also it should be noted that the v4 still has a ux module that you can use - it just has fewer methods. The release has more details about what's in it and what got removed.

[arthurfiorette]

Why the UX package couldn't just re-export some methods from all the "recommended" libraries? It would keep consistency across all codebases, keep "built-in" support for more than what it previously had and would require no need to implement anything manually.

---

Regarding #999 (reply in thread)

1. It wouldn't lock-in anyone, we can just ignore the provided ux package.

2. Can simply be solved with peer dependencies

[gregsadetsky]

small note that in the announcement message (from March), you have:

For hyperlinks: hyperlink

I believe that's the wrong library -- the npm hyperlink library is about finding dead links / preventing link rot. it's not about hyperlinks in the terminal.

were you thinking of https://www.npmjs.com/package/terminal-link ? or probably https://www.npmjs.com/package/hyperlinker ?

cheers

[mdonnalley]

Good catch! I'll update the comment. We also now have the "official" list of recommendations here: https://oclif.io/docs/user_experience