Odd crash on Expo when minified and in production mode

[trajano]

Prior Issues

• https://stackoverflow.com/questions/73788057/react-native-project-crashing-with-redux-toolkit
• https://stackoverflow.com/questions/74283724/expo-crashes-with-redux-toolkit
• Also have a long discussion here https://forums.expo.dev/t/expo-go-with-react-redux-crashes-on-published-app-but-works-in-local/67949/8

What is the current behavior?

The app crashes immediately. Note this does not occur if the app is not minimized or if in non-production.

Steps to Reproduce

I am unable to make a MVCE to show this.

But this can be recreated in my app https://github.com/trajano/spring-cloud-demo (it's not a trivial app, but to make it crash I when I add the following to https://github.com/trajano/spring-cloud-demo/blob/rework/expo-app/authenticated-context/AuthenticatedProvider.tsx

import { configureStore } from "@reduxjs/toolkit";
export const store = configureStore({
  reducer: {},
});

What is the expected behavior?

Not crash.

Environment Details

"@reduxjs/toolkit": "^1.9.0",
"react-redux": "^8.0.5",
"redux-persist": "^6.0.0",
"expo": "^47.0.6",
"react": "18.1.0",
"react-dom": "18.1.0",
"react-native": "0.70.5",

[trajano]

For me to fix

import { legacy_createStore as createStore } from "redux";
export const store = createStore((state = 0, action) => state);

I had to remove in lib/redux.js this block

/*
 * This is a dummy function to check if the function name has been altered by minification.
 * If the function has been minified and NODE_ENV !== 'production', warn the user.
 */

function isCrushed() {}

if (process.env.NODE_ENV !== 'production' && typeof isCrushed.name === 'string' && isCrushed.name !== 'isCrushed') {
  warning('You are currently using minified code outside of NODE_ENV === "production". ' + 'This means that you are running a slower development build of Redux. ' + 'You can use loose-envify (https://github.com/zertosh/loose-envify) for browserify ' + 'or setting mode to production in webpack (https://webpack.js.org/concepts/mode/) ' + 'to ensure you have the correct code for your production build.');
}

As to why it would work without it, I am not sure, it does not look like it should have any side effects. However, this fix does not propagate to @reduxjs/toolkit I think it's doing something extra but I am not certain what.

[markerikson]

I'm kind of confused. The check you're pointing to is in the redux core createStore function, but this only happens if you use RTK's configureStore, and works fine with just createStore by itself?

[markerikson]

@timdorr @phryneas so tracing back the history of those lines, it dates back to this issue/PR in late 2015:

• Warn when code is uglified but not envified #1029
• warn user when using minified code outside of NODE_ENV 'production' #1075

Worst case I think we'd be okay to remove that warning?

[timdorr]

I know I'm the one that originally merged this, but I think it's probably better to remove it. As we move towards ESM being more and more popular, relying on a Node-specific global is going to become less likely to be present and increase these kinds of issues.

At least, that's my general sense of things. I have no data to back that up, so just take it as a hunch.

[markerikson]

Eh, I'm less worried about the NODE_ENV thing than I am the "does this 'non-minified code' warning even still make sense in 2022?" question :)

[trajano]

I'm kind of confused. The check you're pointing to is in the redux core createStore function, but this only happens if you use RTK's configureStore, and works fine with just createStore by itself?

The check I am poiting at is in lib/redux.js or redux. The toolkit does import * from redux so I was trying to hunt down what could cause it. Like I said the behaviour is sort of weird at least let me see a JS crash trace or allow me to wrap in a try-catch and log the error, but so far and I haven't been able to pull it out on its own.

[markerikson]

@trajano : yes, I know, that's why I'm confused why you're saying this happens with RTK's configureStore(), but not just the core createStore(). That code is in the module-level redux/src/index.js file, so it runs as soon you import anything from redux. Therefore, this error shouldn't depend on whether or not you're using RTK.

[trajano]

Well a similar error occurs on RTK (just crash) but not l don't know what exactly is causing it. I am just pointing out that the patch I did on redux.js seems to fix createStore in redux. Maybe there's similar code in RTK, but by the time I can "see" it, the code is minified to an unreadable state already.

[markerikson]

Yeah, I understand that you're seeing this crash when you call configureStore().

But because this code is in the redux core, I'm asking:

does this also crash if you just use const store = createStore()?

because the "RTK" part shouldn't matter here.

[trajano]

does this also crash if you just use const store = createStore()?

You mean

import { legacy_createStore as createStore } from "redux";
export const store = createStore((state = 0, action) => state);

Yes it crashes unless I remove that isCrushed check. So if that check was removed at least the "legacy" version of Redux would still work.

[phryneas]

If that check was removed, all versions would - this is really just the core implementation.

[trajano]

If that check was removed, all versions would - this is really just the core implementation.

you mean it would cause crashes on other places if that isCrushed check was removed @phyrneas?

[markerikson]

No. We're saying that there is only one place that check exists, in the redux core library index.js file. So it doesn't matter if you're using "legacy Redux" (the redux package), or Redux Toolkit (which depends on the redux package) - removing that check from redux would fix this everywhere redux is used.

In other words: This is not a "Redux Toolkit" problem. This is a "Redux core" problem.

I'm going to go ahead and transfer this issue back to the core repo.

[trajano]

Ah ok. Well the fix I did for for core that's for sure. So it may be a diffrerent one. However, let's see if we can clear off that check at least I'd have legacy redux as an option.

However just having

import '@reduxjs/toolkit';

with minified and process.env === PRODUCTION is enough to cause my app to crash with no useful traces that I can find.

[markerikson]

Yes, that's exactly my point.

Redux Toolkit, the @reduxjs/toolkit package, imports methods from the redux core.

That isCrushed check is in the redux/src/index.js module file.

It runs as soon as you import anything from the redux package.

Therefore, yes, importing RTK triggers this crash because importing anything from redux runs that check.

It's not RTK that's the issue. It's the redux index file.

[trajano]

It's not RTK that's the issue. It's the redux index file.

Hopefully that's all it is. Eagerly awaiting a release.

[markerikson]

Okay, this is finally out in https://github.com/reduxjs/redux/releases/tag/v4.2.1 . Sorry for the delay!