Replace `@isaacs/cliui` with `cliui`

[MichaelDeBoey]

Now that yargs/cliui#165 is merged, there whole reason for @isaacs' fork's existence is gone, so we should get people back to the original project

---

This will also help to get rid of strip-ansi (see #122), string-width (see #194) & wrap-ansi (see #230) usage

---

npx github:Fuzzyma/e18e-tools @isaacs/cliui -n 100 -q -o md  -U https://npm.devminer.xyz/registry

#	Downloads	Traffic	Version	Package	PR
1	235.37M	1433.15 GB	^8.0.2	jackspeak	isaacs/jackspeak#21
2	16	97.42 KB	^8.0.2	code-migration-helpers
3	4	24.36 KB	^8.0.2	bteb-portal

npx github:Fuzzyma/e18e-tools @isaacs/cliui -n 100 -q -o md -D -U https://npm.devminer.xyz/registry

#	Downloads	Traffic	Version	Package	PR
1	236	1.44 MB		@paalan/tailwind-ui
2	8	48.71 KB		lnpkg
3	4	24.36 KB		@moclojer/mockingbird-cljs

[43081j]

this is a great one!

i think we will find usages more easily through github search too, but maybe not. worth a look

[MichaelDeBoey]

@43081j I can't seem to find other issues where we use GitHub search, so if you could provide me the correct link/query, I'm happy to include those as well in the description

[43081j]

im wrong i think!

its almost entirely from jackspeak by the looks of it:
https://github.com/search?q=%22%5C%22%40isaacs%2Fcliui%5C%22%3A%22+AND+path%3Apackage.json+AND+NOT+is%3Afork&type=code

[isaacs]

The new version of cliui still fails all the tests that were the reason I forked it in the first place.

[43081j]

Do you have any examples? We should fix those. If you have links to issues or anything, do share 🙏

[isaacs]

Do you have any examples? We should fix those. If you have links to issues or anything, do share 🙏

See all the test failures on this PR for example. Any drop-in replacement should work without having to update snapshots, or else it's changing behavior, and not a valid drop-in replacement.

Look, I'm not trying to be difficult, and I think your goal with this project is noble and good, but if the use of npm: aliases in package dependencies causes problems with your dependency analysis tool, then that tool is incomplete and should be fixed. Going around pushing library authors to stop using a package management feature that's been a part of the ecosystem for over a decade, is kind of a crazy ocean-boiling approach, tbh. If that's your metric of success, it's doomed, I'm sorry.

[43081j]

if the use of npm: aliases in package dependencies causes problems with your dependency analysis tool, then that tool is incomplete and should be fixed. Going around pushing library authors to stop using a package management feature that's been a part of the ecosystem for over a decade, is kind of a crazy ocean-boiling approach, tbh. If that's your metric of success, it's doomed, I'm sorry.

can you clarify this? what part of our tooling do you think has something to do with npm: aliases? or whose actions?

i'm not aware of anything to do with that unless i've just forgotten somehow

i'm not concerned with how you declare your dependencies. your fork of cliui exists to solve a problem, so the correct solution is to now work on solving that in cliui itself. if someone manages to do that, the fork goes away. what you linked shows that there is work to do there - but its not a permanent blocker, someone just needs to find time to figure out.

[isaacs]

Oh, sorry, maybe I'm mistaken about that? This issue was initially brought to me as npm: aliases in my fork causing problems with the dep analysis tools, I thought that's what this was trying to resolve.

so the correct solution is to now work on solving that in cliui itself.

This is a mistaken assumption.

My fork of cliui happened initially because I needed hybrid cjs and esm support, and what was there did not properly maintain whitespace in the way that I wanted it to. The authors of cliui took an approach that is reasonable for their (ie, yargs') purposes, but it doesn't work for mine (tap, glob, and my other tools that use Jackspeak to produce --help output). Hence, fork. It's not something that needs to be resolved.

The "correct solution" is for us to proceed in our own directions indefinitely.

Would you feel the same way if I'd changed the name, as well as the implementation?

I don't think it's worthwhile for anyone to "spend time to figure it out". What exists today is a perfectly reasonable solution to a very minor problem. I'm not sure what tangible issue you're trying to solve, maybe if that was more clear, it'd be clearer what needs to happen to address it.

[43081j]

The "correct solution" is for us to proceed in our own directions indefinitely

It is if your intention was always to diverge. I wasn't aware of that, I only knew about the ESM/CJS part. Thanks for the context, it makes sense that you might want to keep your fork in that case.

If the fork only exists to fix something or add a feature that may one day end up in the original (my assumption), it would've been correct to try merge back in.

Anyhow - it sounds like the right thing to do now is contribute to your fork to use fast-wrap-ansi/fast-string-width so it can have the same perf gains as the original cliui (assuming that doesn't break your tests).

[MichaelDeBoey]

@isaacs Looking at the small amount of commits you added in your fork and quickly looking at the linked issues/PRs, my gut tells me we could fix most of these problems upstream.
We could then update jackspeak to get rid of your fork (Node v20 supports require of ESM modules)

But as @43081j said: somebody would need to be able to spend some time on it

[isaacs]

Well, this conversation inspired me to do what I'd meant to for some time now, and vendor the Sindre modules into cliui so that they can be accessed easily, and bundled together in a single file for a faster-starting cli.

If you want to replace any of the vendored modules in @isaacs/cliui/src/* folder with faster variants, I'm totally fine with it, as long as the tests pass.

I have no intention to get rid of my fork.

[43081j]

@isaacs sounds good to me

we should be able to use fast-wrap-ansi and fast-string-width quite easily. if tests somehow fail, we should track it upstream in each of those projects

the intention was never really to get rid of your fork. i didn't realise it had diverged more than fixing some things that were expected to land upstream one day. absolutely makes sense to keep both now 👍 would love to see someone contribute to the same perf improvements to your fork at some point