Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues with immer version v9.0.13 #2315

Closed
thenriquedb opened this issue May 11, 2022 · 11 comments
Closed

Issues with immer version v9.0.13 #2315

thenriquedb opened this issue May 11, 2022 · 11 comments

Comments

@thenriquedb
Copy link

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

image

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
Copy link
Collaborator

markerikson commented May 11, 2022

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
Copy link
Collaborator

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

@cmorbitzer
Copy link

cmorbitzer commented May 12, 2022

Can confirm that @thenriquedb's suggested solution, rolling back to [email protected], works for now. Thank you!

@francois-codes
Copy link

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 [email protected] ?

@cdauth
Copy link

cdauth commented May 12, 2022

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
Copy link

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
Copy link

cdauth commented May 12, 2022

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
Copy link

@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
Copy link

cdauth commented May 12, 2022

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

@thenriquedb Can you confirm that the issue is solved?

@markerikson
Copy link
Collaborator

SHould be fixed now that Immer 9.0.14 is out.

@HarshitMadhav
Copy link

HarshitMadhav commented May 23, 2022

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants