0.29.0 Upgrade Guide
adispring opened this issue Β· comments
π Added:
π₯ Breaking Changes:
- #2603
without
first argument must now be array - #2938 change
propEq
/pathEq
parameters order: comparing value first,prop
/path
second. This change will makepropEq
/pathEq
parameters order be consistent topropSatisfies
/pathSatisfies
- #3272 improve
of
to work with more Applicative types.of
now receives two parameters instead of one: the first parameter is type Constructor, and the second parameter is the value to be wrapped
π‘ Changes:
- #2524 make
assocPath
overwrite primitive values with keys in path - #2603 improve
without
andintersection
time complexity - #2624 add Map and Set support to
toString
- #2985 improve
clone
performance - #2997 improves
_reduce
to returnacc
when thelist
is null/undefined - #3158 use first flags property, and support dotAll flag in
_cloneRegExp
- #3197 improve
min
andmax
logic - #3210 remove placeholder check from
identical
- #3222 fixes merge with nil objects of
mergeWithKey
,mergeAll
,mergeLeft
,mergeRight
,mergeWith
- #3231 remove
curryX
dependency for internal transducer creator functions - #3234 fix
groupBy
enters a broken state when used as transducer - #3246 fix
dropLast
with negative and zero param when used as transducer - #3248 split
_reduce
to_xReduce
(for transformers) and_reduce
(for reducers) - #3261 fixes can't handle no prototype objects in
clone
- #3360 make
traverse
andsequence
Fantasy-Land compliant
β Miscellaneous
- #3223 upgrade and fixing up eslint-plugin-import
- #3270 update package.json exports section to support node version 10 to 17
π Documentation fixes: #2004 #2116 #2368 #2797 #2955 #3010 #3220 #3221 #3228 #3235 #3242 #3244 #3263 #3291
βοΈ Testing improvements: #3269 #3276
Build and other internal improvements: #3018 #3082 #3100
Many thanks to all the contributors supporting this release.
We'd also like to call out to all those who submitted issues or PRs that we've chosen not to include. It's often easy to forget that the attempts that fail are often just as important to long-term success as those that succeed. Thank you for all your great work! π
It feels like the breaking changes are kind of glossed over, like, R.of
, R.propEq
, and R.pathEq
could mean quite a few changes for large code bases (mine included). Feels like breaking changes should be highlighted, or at least separated, from non-breaking changes
It feels like the breaking changes are kind of glossed over, like,
R.of
,R.propEq
, andR.pathEq
could mean quite a few changes for large code bases (mine included). Feels like breaking changes should be highlighted, or at least separated, from non-breaking changes
I have split breaking changes from normal improve changes.
looks like export function of<T>(x: T): T[];
is still the old definition in 0.29.0 @types/ramda
btw what's the point of changing order in propEq ? I think the arguments should be sorted by how static they are.
now the prop name/path is the most static element in the chain, so it should be placed first. IMO it would have been way better to swap propSatisfies order instead.
consider this:
import { cond, propEq, T as _, flip } from 'ramda'
const eq = propEq('hour') // this has to be now changed to flip(propEq)('hour')
type OwnProps = {
hour: number
}
export const ClockBullet = cond<[OwnProps], JSX.Element>([
[eq(1), () => <IconClockHour1 fill="white" color="#228be6" />],
[eq(2), () => <IconClockHour2 fill="white" color="#228be6" />],
...
[_, () => <IconClock fill="white" color="#228be6" />]
])
What sort of versioning scheme is ramda following? Don't the breaking changes warrant a v1 release?
What sort of versioning scheme is ramda following? Don't the breaking changes warrant a v1 release?
No. Breaking changes are allowed in semantic versioning when you are in 0.*
No. Breaking changes are allowed in semantic versioning when you are in 0.*
Major version zero is for initial development; ramda has been available for I-dont-know-how-many-years and has thousands of dependent packages. Isn't it time to declare v1 and start adhering to some stricter API stability requirements?
Would have appreciated a param swap on R.gt
, R.gte
, R.lt
, and R.lte
as well. It always seemed like I should be able to do this:
const isGreaterThanThree = R.gt(3);
Would have appreciated a param swap on
R.gt
,R.gte
,R.lt
, andR.lte
as well. It always seemed like I should be able to do this:const isGreaterThanThree = R.gt(3);
see the discussion in
#1497
I really don't understand why you're switching the parameters order in propEq
and pathEq
. I use these functions all over my codebases and changing every single function call just to continue using Ramda's latest version is very inconvenient. I was tempted to go to 0.29.0 to fix the groupBy
issue when used as a transducer, but now, I hesitate to do so...
Why not coming up with new names, but leaving the original functions intact? Maybe propEquals
, propIsEq
or even propEq2
... I know it's not as elegant, but it wouldn't break all your users. That's actually what Rich Hickey is proposing in his talk Spec-ulation Keynote: sequence Breaking Changes are Broken.
Just to be clear: I absolutely LOVE Ramda and I include it de facto in each NodeJS or Javascript project I work on. So it's not a rant, but a recommendation for improvement.
#2938 change propEq/pathEq parameters order: comparing value first, prop/path second. This change will make propEq/pathEq parameters order be consistent to propSatisfies/pathSatisfies
I would prefer revert this change, based on the most common use case, discussed in the below issues/prs:
Finally, respectfully, the best solution would be to admit that we already #1286 this and to revert, preferably quickly.
This change was happened and reverted before. Aligning function's props order is the same reason as it was introducing at the last time. There is no stronger reason for introducing the same change again. It also breaks the expectation of the semantic versioning convention if only bumps the minor version. (I know anything can happen in 0.x, but many bot settings like dependabot ignore rule is set to ignore major version and expecting no breaking change in minor version update)
Maybe it's a naming problem as stated in this comment:
#2938 (comment)
the order is important. valueAtProp has the right order of arg references so it's a great candidate (but perhaps is missing the word "equals"/"eq")? eqAtProp or even eqProp then? propEq is not a good candidate however, because it implies that the first argument should be the equality check somehow.
Could we clone the current propEq
to eqProp
in the minor version upgrade and bring the order change back in version 1.0?
It would be easier for the users gracefully replacing their current usage of propEq
with the new eqProp
before major version update.
Thanks all for the feedback. It seems the comments in favor of the old order far outnumber those in favor of the new order. I like the logic presented here, but from the reception of this change we need to go about any breaking changes we might make to these functions in a more deliberate manor, maybe after 1.0 as well.
I think the simplest thing to do is revert this change asap, release 0.30.0, and possibly revisit at a later date.
I will try to put up a PR at some point this week.
Please don't change the order back. I refactored thousands of lines of code in multiple repos to change the order while also delivering tickets.. I'll have to lock that project to 0.29.0 .. this is really amateur guys, just release a 1.0.0 already so you start taking this library seriously.
Just a reminder for everyone, the rules of semver dictact that any update for 0.x
are considered breaking. See here: https://semver.org/#spec-item-4.
Though I would also argue that ramda
should have been made 1.0.0
long ago