Repository navigation
Vendor ts-toolbelt types and drop dependency #148
Description
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.
Activity
[-]ts-toolbelt hasn't been updated in 5 years now[/-][+]Vendor ts-toolbelt types and drop dependency[/+]Harris-Miller commentedon Aug 18, 2026
I've wanted to move away from
ts-toolbeltfor a while now, actually. It's the type library that was used when everything was defined directly in@types/ramdavia 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 tots-toolbeltand if we migrate without breaking changes, awesome! If not, we'll have to bumpramdaandtypes-ramdato0.33.0simultaneously to show users that breaking type changes will be expectedI 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 commentedon Aug 18, 2026
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.