Ramda ts proposal #3329
Replies: 8 comments 6 replies
-
@kedashoe bump |
Beta Was this translation helpful? Give feedback.
-
Spoke to @Harris-Miller via email, we are going to try a separate 'ramda/types' repo for now. |
Beta Was this translation helpful? Give feedback.
-
I have had no time to dedicate to Ramda for several months, and won't for another two weeks or so, but after that, I expect to be back, and pushing toward |
Beta Was this translation helpful? Give feedback.
-
@kedashoe @CrossEye Ok I'm back. Here's the plan.
I'm working on standing up Let me know what you guys think about this plan |
Beta Was this translation helpful? Give feedback.
-
UpdateAt the time of making the issue, I confirmed that what I have in At this point, I'm ready to make the repo public and do that. I will need some help setting up npm publishing. Not sure if ramda owns the I am also working on a Master List which defines what work is needed for each function's type definitions. Once that is done I'll split it out into manageable chunks, prioritize, and start reaching out for community help. Let me know if you have any questions. Thank you! |
Beta Was this translation helpful? Give feedback.
-
Kevin and Scott,
I was hoping we could make ramda/types <https://github.com/ramda/types>
public now and your help with a few items
First
a) Get publish pipelines set up for it
b) Get an MR set up in @types/ramda to re-export ramda/types
c) Profit!
At minimum, I would like to get the ramda/types repo made public so I can
manage the work ahead via Github issues/projects, etc, and work can at
least begin in the DefinatelyTyped repo until we're ready to full migrate
things over to ramda/types
I'm very much invested in getting Ramda typings to where they should be.
Typescript adoption has grown considerably over the past few years and at
my company the lack of good ramda types is the major blocker for full
adaption. I've heard elsewhere that that is the main case as well. One of
my roles as a Technical Lead at my company is to help drive innovation, and
that blocker for adaption has been challenging. Ramda works *very* well
with modern web development, especially in React-land where everything is
immutable. I can't tell you how many bugs I have solved by pointing to my
junior devs simply by introducing them to ramda to use over lodash.
First-class typings, IMHO, will help excel Ramda adoption by the community
at large
Thank you!
…On Tue, Nov 29, 2022 at 6:30 PM wangzengdi ***@***.***> wrote:
@Harris-Miller <https://github.com/Harris-Miller> First, thanks for your
contribute. There are some hard but important problems that need to solve
for ramda working friendly with ts, I list some here:
1. how to do check and reason composed functions' type easily and
correctly in pipeline (compose functions with compose/pipe) .
2. how ts support curry friendly. when compose curried functions in
pipeline, curry make things terrible.
Do you have any plan or thought about how to resolve the above problems?
—
Reply to this email directly, view it on GitHub
<#3329 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAVCTK5TNQTFHLSHQNGB6HLWK2U4PANCNFSM6AAAAAARMOLT5I>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Harris Miller
301-404-7090
***@***.***
|
Beta Was this translation helpful? Give feedback.
-
I'll start another discussion in that repo for it. Thank you!
…On Thu, Mar 9, 2023 at 4:12 PM Kevin Wallace ***@***.***> wrote:
The repo is now public! I can help set up the public action as well
—
Reply to this email directly, view it on GitHub
<#3329 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAVCTKYBYFTR5JNAWNNQBOLW3JPVRANCNFSM6AAAAAARMOLT5I>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Harris Miller
301-404-7090
***@***.***
|
Beta Was this translation helpful? Give feedback.
-
Side question: any thoughts on releasing `0.29.0`? `master` is currently 55
commits ahead of `v0.28.0`, and there are a lot of great bug fixes and at
least one new function (`isNotNil`) in there
On Thu, Mar 9, 2023 at 6:20 PM Harris Miller <
***@***.***> wrote:
… I'll start another discussion in that repo for it. Thank you!
On Thu, Mar 9, 2023 at 4:12 PM Kevin Wallace ***@***.***>
wrote:
> The repo is now public! I can help set up the public action as well
>
> —
> Reply to this email directly, view it on GitHub
> <#3329 (reply in thread)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAVCTKYBYFTR5JNAWNNQBOLW3JPVRANCNFSM6AAAAAARMOLT5I>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
--
Harris Miller
301-404-7090
***@***.***
--
Harris Miller
301-404-7090
***@***.***
|
Beta Was this translation helpful? Give feedback.
-
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 responseI'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 forramda
is the biggest hurdle for me to get others to adopt over saylodash
, and is why I've begun contributing with my recent PRsProposal 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 thets
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 thets
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 adevDependency
, 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 intomaster
after reaching specific milestonesDevelopment and Release
Regardless of which strategy is chosen, development and release remain the same
For
@ramda/types
, this meansdevelopment
->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 oframda
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!
Beta Was this translation helpful? Give feedback.
All reactions