[Request] eliminate third-party dependencies on @clack/core + @clack/prompts #626

Activity

1. firxworx

   added

   enhancementNew feature or requestNew feature or request

   on Oct 20, 2026
2. github-project-automation

   added this to Triage Boardon Oct 20, 2026
3. github-project-automation

   moved this to Needs triage in Triage Boardon Oct 20, 2026
4. 43081j commented on Oct 21, 2026

   

   43081j

   on Oct 21, 2026

   Last edited by 43081j

   Collaborator

   More actions

   there is a balance. these dependencies de-dupe very well in wider dependency trees as they're used by quite a lot of dev tools in the ecosystem. on top of that, AI or not, it increases the burden on us (the maintainers) to maintain code unrelated to what clack exists for.

   i understand wanting to secure the supply chain, and i spend a large part of my time doing that, but i don't think the solution is "never use dependencies". that's a quick way to add noise to your repo, lose focus and, worse, slop.

   i'll wait for an opinion from @dreyfus92 but i don't see a reason to drop them.

   also worth noting, commander is a CLI builder (i.e. it generates usage, --help, and parses args), while clack is a CLI renderer (prompts library). all CLI renderers ultimately have to calculate the visual string width, so barely any of them have zero dependencies because of that.
5. dreyfus92 commented on Oct 21, 2026

   

   dreyfus92

   on Oct 21, 2026

   Member

   More actions

   hey @firxworx, thanks for taking the time to write this up, supply chain stuff is worth raising. agree with james here though. @clack/prompts pulls in 4 tiny packages, one of them is being maintained by james, and all of them sit at 20M+ weekly downloads, so they're almost certainly in your tree already thru other tools. vendoring them wouldn't remove them, it'd just add a copy we have to maintain, increasing maintainance burden. string width is exactly the kind of niche code where bugs kide (cjk, emoji, ansi stuff).

   your supply chain concern is fair though. fast-wrap-ansi and sisteransi already publish with npm provenance, fast-string-width and fast-string-truncated-width don't. getting provenance on those two seems like the better win here than dropping them.
6. firxworx commented on Oct 23, 2026

   

   firxworx

   on Oct 23, 2026

   Author

   More actions

   hey @43081j and @dreyfus92 I really appreciate the thoughtful and detailed responses.

   Paul I really appreciate that you looked at each dependency and noted the lack of npm provenance on fast-string-width and fast-string-truncated-width.

   I agree that "never use dependencies" is not a general solution... my own general philosophy considers if a dependency:

   • is small (or the usage of it is small such as calling a function or two from a huge library) and;
   • is not likely to change (for example you are not effectively outsourcing to a maintainer the work of staying on top of something hairy or changing)

   ...then consider bringing it into the codebase.

   At first blush it seemed like that's the case for all but y'all bring up a good point about string width being pretty niche, and I admittedly didn't notice that one of you guys is behind one of them!

   A few thoughts regarding popularity:

   • a good chunk of the popularity of these packages is your own work such as clack itself (congrats!)
   • considering an attacker's perspective, the more popular a dependency is, and the sweeter the targets that depend on it (such as corporate and government codebases vs. lower value consumers), the juicer of a target it may be

   All said I respect your guys decision and really appreciate you taking the time and care you put into responding, I'm happy to call the issue closed if you are :)

   ❤️React with ❤️1Reacted by paul valladares