Arg, painful. PR welcome or I'll need to rollback.

@TrySound what do you think we should do here?

It feels like we cannot win with the imports 😅

Also, @TheKas what do you think we should do here?

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

I'm happy to deprecate 5.2.0 for now while we decide if people think that is best

You can do ugly and use module.exports in sources
Or yeah just bump 6.0 (though this is where I would drop default export)

Or yeah just bump 6.0 (though this is where I would drop default export)

Is the current 5.2.0 commonjs setup what we want to carry forward into 6.0.0?

Yeah, looks fine to me. I tend to avoid umd these days. ESM in browser is good enough alternative.

Ideally, people would not need to change their existing memoize-one commonjs usage for 6.0.0. I am not sure why the changes in 5.2.0 would have broken bundlers. netlify/cli#2202

Because rollup produces "module.exports = () => {}" when only default export is present by default. When named export is added it produces "exports.default;exports.named". The latest rollup version requires this configuration (exports: default | named) explicitly with warning.

Okay. How do you think we should proceed? rollback named import support for 5.x and just use the default?

I think unwinding the support of a named import is the cleanest path for now (and deprecating 5.2.0)

Can you take a look at #117 @TrySound ?

This is the plan unless there are objections:

1. merge removing named import #117
2. release 5.2.1
3. deprecate 5.2.0

I'll do these steps in a few hours

@ehmicky the addition of a named import in 5.2.0 has been removed in 5.2.1 and 5.2.0 has been deprecated. Thank you for raising this

https://github.com/alexreardon/memoize-one/releases/tag/v5.2.1

@JGAntunes I created a PR to netlify/cli to upgrade memoize-one and move back to the default import netlify/cli#2218

Thanks for fixing all of this @alexreardon

I am wondering whether it might have been better for 5.2.1 to export a function with two properties default and memoizeOne (as opposed to reverting to 5.1.1 behavior)?

> memoizeOne
<ref *1> [Function: memoizeOne] {
  default: [Circular *1],
  memoizeOne: [Circular *1]
}

This would have made 5.2.1 work both for 5.1.1-compatible users and for 5.2.0 ones. Otherwise, the 5.2.1 release creates a second breaking change for users who changed their import to match the first breaking change (example with Netlify CLI).

However, now that this has been released in 5.2.1, I would suggest not trying to fix it anymore, to avoid a third breaking change.

That being said, thanks a lot for being so proactive on this issue and for opening a PR in our repository ❤️
Thanks for maintaining this repository too, this is a really useful one. :)

Also don't be afraid to release a 6.0.0! Cleaning the duplicated import makes sense.

With this issue, there were no great options. Sometimes we are choosing between bad options.

5.2.0 introduced an unintentional breaking change for CommonJS consumers. This version was released 22nd April. It came to my attention on 24th April (< 48hrs later) that 5.2.0 introduced an accidental breaking change (this Github issue)

Unfortunately, there were no good options for consumers. Keep in mind that if consumers continued to use their existing code which used the default import on 5.2.0 then their code would break.

Some options:

• release a 6.0.0 and deprecate 5.2.0: not great as people on 5.2.0 would need to bump to 6.0.0 to get the fix
• release 5.2.1 which fixed the issue, keep the named import and deprecate 5.2.0. It looks like @ehmicky might have found a way to do this - but it would need to be validated that this approach would work well with all our bundle types. At the time I did not consider this approach (it is not a standard approach), and I am not sure how it would even play with ESM.
• release 5.2.1 and deprecate the new (broken) 5.2.0. It felt like this option was the best of the available options

→ 5.2.1 is a breaking change from 5.2.0, but 5.2.1 is not a breaking change from 5.1.1
→ 5.2.0 is now deprecated on npm and consumers would only now be broken if they shifted over to the new named import

I am open to charting a different course here. I thought the approach I took was the least harm. The only other path I think we could take is release 6.0.0 and deprecate 5.2.1. Then 5.1.1 would be the last 5.1x release, and consumers would need to jump to 6.0.0

I'm open to releasing a 6.0.0 if people are keen on that

• deprecate 5.2.1 (which is a breaking change from 5.2.0 (which is broken for default imports with CommonJS)
• release 6.0.0

I'm keen to know what others think

My thoughts...

Do this:

release 5.2.1 and deprecate the new (broken) 5.2.0. It felt like this option was the best of the available options

Then make the change which alters the export.
Then do this:

release 6.0.0

Just to ensure shared understanding:

5.2.1 is already released (which is a breaking change from 5.2.0)

I have no good solution to allow a named import right now @jesstelford. The strategy @ehmicky might work, but it would take a good amount of time to validate well.

So releasing a 6.0.0 would simply be a guard for people on 5.2.0 that they would need to modify their code to move to 6.0.0 (which does seem worthwhile)

So the current problem is that some people did upgrade to 5.2.0 and move to named imports (the package was published for ~40hrs). Now when they upgrade to 5.2.1 they will break.

So it feels like we might have to deprecate 5.2.1 and release a 6.0.0 to protect those people currently on 5.2.0

I'm now pretty convinced doing a 6.0.0 is the right course of action (it wont have named imports) and deprecating 2.5.1 so that anybody on 2.5.0 doesn't upgrade to 2.5.1

I will aim to do this pretty soon if I can. I'm just waiting for more input to validate this is the correct course of action. @danieldelcore and I think this is the right approach, but I want to get somebody else's thoughts before proceeding

I say you leave it as-is right now:

• 5.1.1 no named export
• 5.2.0 named export. Deprecated
• 5.2.1 no named export
• 6.0.0 doesn't exist. Won't be released any time soon

Edit 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 to 5.2.1 quickly.

For those with dependabot setup, they'll get the 5.2.1 notification just like the one for 5.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 👍

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.

@Andarist 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)

Hi, I made a wrong comment #117 (comment) and @alexreardon inferred that I was in this situation. This is not true, don't bother keeping the broken 5.2.0

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