`5.2.0` introduces a breaking change
See original GitHub issueThe 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] }
Issue Analytics
- State:
- Created 2 years ago
- Reactions:3
- Comments:28 (23 by maintainers)
Top Results From Across the Web
Mochawesome updated to 5.0.0 introduces a breaking change.
Mochawesome just dropped v5.0.0 today which introduces a breaking change. If you have mocha@5.2.0 installed you will get an error:.
Read more >Breaking Changes
A breaking change is any change which modifies the public interface to a module in such a way that causes any consuming modules...
Read more >When and how to make breaking changes
As stated in the introduction, our goal in this research is to create a high-level map of values and practices relating to breaking...
Read more >Changelog - Cypress Documentation
This change adds consistency around how .within() behaves across commands. ... Read our Migration Guide which explains the breaking changes in more detail....
Read more >What's new in Celery 5.0 (singularity)
The command line interface has been revamped using Click. As a result a few breaking changes has been introduced: Postfix global options like...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
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.