memoize-one: `5.2.0` introduces a breaking change
The 5.2.0
release accidentally introduced a breaking change when using CommonJS require()
.
5.1.1
:
> require('memoize-one')
[Function: memoizeOne]
5.2.0
:
> require('memoize-one')
{ default: [Function: memoizeOne], memoizeOne: [Function: memoizeOne] }
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 3
- Comments: 28 (23 by maintainers)
Okay, based on feedback I think I have acted correctly and followed SemVer. I will close this issue for now.
This whole issue was super stressful! The last thing I want to do is cause anybody friction in their consumption.
Thanks everybody for your input
Yep, my stance on this is very similar to @jesstelford and @ehmicky . Stuff like this happens from time to time - we need to be pragmatic here, the current versions are OK - and whoever has adjusted their code already with the named export in mind… can just revert their changes (there shouldn’t be that many of such people anyway). Semver is just a human-based guideline anyway - somebody’s bug fix is always somebody’s breaking chance if we consider software at scale so it’s not worth stressing things like this too much.
I say you leave it as-is right now:
5.1.1
no named export5.2.0
named export. Deprecated5.2.1
no named export6.0.0
~ doesn’t exist. Won’t be released any time soonEdit to add:
40hrs isn’t long for folks to have upgraded their imports. Those who have can easily revert their commits. Sucks for them, but that’s the nature of software development. If they can upgrade to
5.2.0
that quickly, they can also upgrade to5.2.1
quickly.For those with dependabot setup, they’ll get the
5.2.1
notification just like the one for5.2.0
.I would definitely classify this as a bug because it broke behaviour in a minor release. But you fixed it in a patch release.
@alexreardon you semver’d correctly 👍
@JGAntunes I created a PR to
netlify/cli
to upgradememoize-one
and move back to the default import https://github.com/netlify/cli/pull/2218I’m now pretty convinced doing a
6.0.0
is the right course of action (it wont have named imports) and deprecating2.5.1
so that anybody on2.5.0
doesn’t upgrade to2.5.1
My thoughts…
Do this:
Then make the change which alters the export. Then do this:
If the current common situation is the ideal situation, but we think it is a breaking change: I am happy to deprecate 5.2.0 and release a 6.0.0