Issues with immer version v9.0.13

[thenriquedb]

Today immer released updated to version v9.0.13 which made my project just suddenly stop working.

After hours of research to try to find out why this is happening, I found that the reason for the problem was the latest version of immer that was released a few hours ago.

I believe that more people may experience the same problem so I decided to share my solution. The temporary fix I found was to use package resolution to force the use of the previous version of the package (v9.0.12).

  "resolutions": {
    "immer": "9.0.12"
  }

[markerikson]

Hmm. If you look at the two PRs listed in https://github.com/immerjs/immer/releases/tag/v9.0.13 , they appear to only have types changes.

However... if you look at immerjs/immer@v9.0.12...v9.0.13 , it lists immerjs/immer#921 , which changes Immer's exports. And that looks like a likely issue.

@thenriquedb : can you put together a project that reproduces this issue?

[markerikson]

Filed immerjs/immer#937 on Immer's side.

[cmorbitzer]

Can confirm that @thenriquedb's suggested solution, rolling back to immer@9.0.12, works for now. Thank you!

[francois-codes]

Thanks @markerikson
How can we help to push this and have a resolution better than deprecating old versions of libraries or telling our users to either change their bundler config or add a package.json resolution for immer@9.0.12 ?

[cdauth]

I am the author of the immer pull request that has apparently broken things. I have opened another pull request immerjs/immer#939 that tries to restore backwards compatibility with older build tools.

However, considering that immer is by far not the only package that is not compatible with Node.js in ESM mode (in fact, redux-toolkit has the same problem, see #1960 and #2200), it would be useful to learn the exact reasons why this change is breaking things, rather than just reverting it.

@thenriquedb I assume you are using webpack? Which version of webpack are you using?

[francois-codes]

However, considering that immer is by far not the only package that is not compatible with Node.js in ESM mode (in fact, redux-toolkit has the same problem, see #1960 and #2200), it would be useful to learn the exact reasons why this change is breaking things, rather than just reverting it.

It's quite clear: older versions of RN and metro bundles are not resolving mjs extensions by default, therefore this is a breaking change.

Il not denying you were trying to fix a legitimate issue in the first place but given the fact that it seams this has broken more that it has fixed, reverting it right away is necessary.

Btw, you can resubmit the PR immediately but use proper semver to flag this as a breaking change - since it is - then you'd still have the fix available for those who need it, without breaking existing behavior which were working fine

[cdauth]

I get that old versions of metro don't seem to support .mjs files (according to facebook/metro#535, the issue has not been fixed yet). The error message that has been reported in immerjs/immer#921 was: error: Error: While trying to resolve module `immer` from file `/Users/<user>/<app>/mobileApp/node_modules/@reduxjs/toolkit/dist/redux-toolkit.cjs.production.min.js`, the package `/Users/<user>/<app>/mobileApp/node_modules/immer/package.json` was successfully found. However, this package itself specifies a `main` module field that could not be resolved (`/Users/<user>/<app>/mobileApp/node_modules/immer/dist/immer.esm.mjs`.

However, the error reported above seems to be a completely different one.

Of course packages could just publish a new major release with ESM support and breaking support with older bundlers. The problem is that most package maintainers don't want to publish a major release for such a “small” change, they rather want to do such a release when there has been a major rewrite of the package. My pull request was an attempt to fix support for Node.js without break existing setups. We have learned now that putting an .mjs module into the module, jsnext:main and/or react-native fields of package.json (I'm not sure which of these fields are actually used by which build tool) will break old build tools. My question would be: Which build tools are actually affected and do any of these use the exports field? Otherwise, just adding an exports field that points to the .mjs module would be a way to fix Node.js support without breaking old build tools.

[francois-codes]

@cdauth yeah you're right this issue is different - I got confused with all the open threads on the topic (and I admit I have been participating in several of them as a swift response is needed)

Im not sure about this specific issue - looks like 9.0.13 was created a month after your PR and may include other changes that could explain that issue.

I know lib maintainers are reluctant to publish major increments, we need to be able to trust semantic versioning. And the "size" of the change is irrelevant to wether it is breaking backwards compatibility or not.

Thanks for your PR, let's hope it gets merged and published quickly to unblock all users who are suffering from it through other libraries, and have had to rely on resolution fixes or post install patches to fix the problem. This is the only it can stop breaking older versions of libraries using unpinned versions of immer - including reduxjs/toolkit

[cdauth]

A new version of immer has been released that attempts to fix this problem.

@thenriquedb Can you confirm that the issue is solved?

[markerikson]

SHould be fixed now that Immer 9.0.14 is out.

[HarshitMadhav]

@cdauth @markerikson yes new version of immer released, fixes this issue but somehow reduxjs toolkit picks up version "9.0.13" of immer from yarn.lock so modified this to use version "9.0.12" or version "9.0.14" as version "9.0.13" of immer is breaking it