Vendor ts-toolbelt types and drop dependency

[connorshea]

ts-toolbelt hasn't been updated in 5 years now and pulling it in as ramda-types does currently pulls in a lot of extra cruft. (because of using import * as _ from 'ts-toolbelt'; we pull in all types from ts-toolbelt even though ramda-types only needs a few of them)

I would propose that ts-toolbelt be removed as a dependency, with the handful of types that this repo actually depends on being replaced by vendored types copied over from ts-toolbelt into this repo. This would remove an extra npm dependency, and also remove a bunch of extra type weight this package currently incurs.

Happy to help if there's interest in this idea, the ramda-types are a not-insignificant portion of typechecking time for an app I work on at my employer.

[Harris-Miller]

I've wanted to move away from ts-toolbelt for a while now, actually. It's the type library that was used when everything was defined directly in @types/ramda via https://github.com/DefinitelyTyped/DefinitelyTyped. The thing keeping me from it is a) Breaking Changes, and b) time. https://www.npmjs.com/package/type-fest is the most widely used alternative to ts-toolbelt and if we migrate without breaking changes, awesome! If not, we'll have to bump ramda and types-ramda to 0.33.0 simultaneously to show users that breaking type changes will be expected

I don't have the free time to dedicate to doing this work myself, but PRs are more than welcome! This is the kind of thing AI Agents are best at too. Systemic changes of migrating from one underlying library to another with the goal being retained behavior that is opaque to the end-user

[connorshea]

The thing keeping me from it is a) Breaking Changes, and b) time. https://www.npmjs.com/package/type-fest is the most widely used alternative to ts-toolbelt and if we migrate without breaking changes, awesome! If not, we'll have to bump ramda and types-ramda to 0.33.0 simultaneously to show users that breaking type changes will be expected

I don't have the free time to dedicate to doing this work myself, but PRs are more than welcome! This is the kind of thing AI Agents are best at too. Systemic changes of migrating from one underlying library to another with the goal being retained behavior that is opaque to the end-user

Agreed on AI being useful for this kind of change, I opened a PR to try it out and it works pretty well. I'm happy to try using type-fest instead of vendoring the types into this repo since the types in #149 are a bit gnarly, but up to you.

This should be fully backwards-compatible, based on the tests added (they all pass on develop as well) and testing I had Claude run through generating a bunch of cases and checking before/after types.