Sounds a bit like the idea behind shadcn/ui. You start from the generated components, but the idea is to fork the code.

(Then they seem to also have added their own kind of dependency management thing to update components, which seems to me to kind of defeat the purpose..)

There are a few usecases for this in some languages, where your functions might as well be class extensions. But you need a huge standard library with non-competitive types, or you end up with deep dependency stacks.

You also run into trouble if your language has side effects (ie, almost all of them). A leftPad that launches a fiber to mine cryptocurrency or sends an http call that fires nuclear missiles can still pass tests. It's hard to guarantee hygiene via tests alone.

The missing piece there, that would be a real value-add over normal package repositories, is that functions can be small enough to simply be done. Function gets marked as such, it can no longer be updated, thus eliminating the risk of supply chain attacks and their ilk. IMO, most packages I actually use, with the exception of web frameworks, ought to fall into this category. My JSON parser should never update. My Knapsack-problem solver should never update.

These are problems that are hairy enough that I don't want to write my own solution, yet tractable enough that there ought to be a solution that never needs to be touched again. Maybe someone finds a better way of doing it, but the way they're currently doing it will never be wrong.

I think the function should be anonymous (have no name). Import should name it.

> remember having this discussion a long time ago that instead of dependencies we should build a function and type hub that lets you pick tested function and type definitions.

Like leftpad?

Your comment is easily misunderstood, my first thought was also “that’s NPM” - but the idea of providing tests and types without implementation is a pretty interesting one.