Hi Ramda team.

As you may have noticed, made a lot of PRs to the ts branch in the past week. @kedashoe sent me this e-mail in response

Hey Harris
Thanks for all the types PRs. Honestly it is too much for me to review! I'm not a typescript expert in any event.
I'd like to propose I create a new repository, @ramda/types, and we move all the type work there. I'll make you a maintainer. There seemed to be some excitement for getting this stuff into @ramda/ramda, but pretty much everyone who was advocating for it has ghosted once I started working on it.
I would say it is more difficult to see a way forward there with the current approach vs working in a separate repo where we can much more easily/visibly release and have people actually use it. At some point in the future maybe we could merge it back into @ramda/ramda

I'm happy to take on that ownership and responsibility, and wanted to use this discussion to go over that option and an alternative

As someone who is personally a huge fan of ramda and works 90% in typescript both professionally and personally, the current state of types for ramda is the biggest hurdle for me to get others to adopt over say lodash, and is why I've begun contributing with my recent PRs

Proposal for type development moving forward

Current typings

The community-driven @types/ramda that lives in the DefinitelyTyped repo works fine currently but is not ideal to keep.

Mostly because of the separation of ownership between the two. @types/ramda is also currently inaccurate in a lot of places, missing types for curried varieties, or straight up missing types for some functions. The block-comments are also copy-paste'd from the core repo and would have to be updated manually and separately and manually. None of that is ideal.

As typescript becomes more ubiquitous in the javascript ecosystem, projects written directly in typescript or have in-repo-defined .d.ts files are becoming more the norm. And for the longevity of @ramda/ramda, this is a pattern that should be adopted. Clearly, with the ts branch, this process is already underway.

Strategies

Separate @ramda/types repo

@kedashoe's proposal is that a @ramda/types repo is created to solely house the typings for Ramda. The way I see this working is by simply moving everything that is new from the ts branch over to the new repo.

The idea here is not to replace @types/ramda with @ramda/types, but rather that @ramda/ramda has the new @ramda/types as a devDependency, and build the types as part of the release pipeline. This way, the types are part of the npm packages, rather than a separate dependency.@ramda/types would never be consumed independently from @ramda/ramda.

There are advantages and disadvantages to this strategy. As stated in the e-mail above, the main reason for this separation is repo ownership. The core @ramda/ramda repo will continue to be owned by the core team, while the @ramda/types repo would be owned by myself and any additional core contributors.

The upside is a separation of PRs, and other GitHub features like discussions, projects, wiki, etc. The downside would be getting @ramda/types into @ramda/ramda. Having these be two separate repos adds a level of complexity that may be more harmful than helpful.

Codeowners in core repo

Alternatively we could go the codeowners route. This essentially keeps everything in the core @ramda/ramda repo and delegates certain files/folders to separate owners for PR approval. This solves the ownership issue @kedashoe pointed out in his e-mail.

A GitFlow style of development would continue with the ts branch getting merged into master after reaching specific milestones

Development and Release

Regardless of which strategy is chosen, development and release remain the same

• a "development" branch is used for PR acceptance over the course of a milestone
• the "development" branch is merged into the "release" branch to trigger a new release

For @ramda/types, this means development -> master, then a PR to bump @ramda/types in @ramda/ramda.

For Codeowners, this means ts -> master

Milestones

The ts branch started out mostly as a copy of @types/ramda. Which is fine, but as I mentioned earlier, there are a lot problems with the state of @types/ramda, so doing an upfront release of ramda with built-in types would end up with possible Breaking changes down the line to types. So ideally, getting all the types in-repo and done correctly would be ideal for an initial release.

That however, may take a lot of time, pushing back the release for "Ramda w/ types" indefinitely. IMHO releasing an MVP version of "Ramda w/ types", with any breaking changes up-front, would be acceptable. Post-MVP would be a series of non-breaking, progressive releases until typing for Ramda is at 100%

I have a lot of experience doing this professionally and is something I can spec out in detail.

Final Thoughts

Personally I think the Codeowners strategy is the way to go. Having a separate repo is likely going to be more of a pain than it's worth. And Codeowner files are very simple to maintain

Thank you to the Ramda core team for the opportunity to help release typings in an official capacity!