Uncaught TypeError: (0 , import_toolkit.createSlice) is not a function

[jrosmith]

Do you want to request a feature or report a bug?
Bug

What is the current behavior?
I'm messing around with monorepos and using a turbo repo template as boilerplate. It contains a React-Native project and a Next.js project, both of which read shared packages from a packages/ui folder. The shared packages gets compiled before anything else with outputs ['.js', '.mjs', '.d.ts', '.d.mts'] in packages/ui/dist.

This all worked without a hitch until I tried to abstract out some components that used react-redux/@reduxjs-toolkit logic. The Next.js project has no problem importing and using the abstracted component, but the React-Native project pukes on startup with the error message Uncaught TypeError: (0 , import_toolkit.createSlice) is not a function.

If the current behavior is a bug, please provide the steps to reproduce and a minimal repository on GitHub that we can yarn install and yarn test.
Even if I do not explicitly use that component in apps/native/App.tsx it still pukes, leading me to think the issue is with the bundle. I've tried the solutions listed here but none of them are working. I've even tried modifying the apps/native/package.json to make sure it did not hoist react-redux or @reduxjs/toolkit, this did not affect the problem.

I've created a reference project. Metro config is located at apps/native/metro.config.js. See packages/ui/src/state for the generic @reduxjs/toolkit logic and packages/ui/src/components/Counter.tsx for the reusable component.

Run yarn install && yarn run dev from the project root to build and run the project. To see the difference in Next.js vs React-Native behaviors, open two browser windows: localhost:19006 and localhost:3000.

What is the expected behavior?
I'm expecting the React-Native version to also be able to import the reusable component by correctly interpreting the shared package.

Please provide your exact Metro configuration and mention your Metro, node, yarn/npm version and operating system.
Metro: 0.80.5
Yarn: 1.22.22
MacOS Monterey 12.7.4

Metro Config:

// Learn more https://docs.expo.io/guides/customizing-metro
const { getDefaultConfig } = require("expo/metro-config");
const path = require("path");

// Find the workspace root, this can be replaced with `find-yarn-workspace-root`
const workspaceRoot = path.resolve(__dirname, "../..");
const projectRoot = __dirname;

const config = getDefaultConfig(projectRoot);

// // Below does not fix the issue
// config.resolver.sourceExts.push("mjs")
// config.resolver.sourceExts.push("cjs")

// // Below does not fix the issue
// const defaultSourceExts = require('metro-config/src/defaults/defaults').sourceExts;
// config.resolver.sourceExts = process.env.RN_SRC_EXT
// ? [...process.env.RN_SRC_EXT.split(',').concat(defaultSourceExts), 'cjs', 'mjs']
// : [...defaultSourceExts, 'cjs', 'mjs'], 

// 1. Watch all files within the monorepo
config.watchFolders = [workspaceRoot];

// 2. Let Metro know where to resolve packages, and in what order
config.resolver.nodeModulesPaths = [
  path.resolve(projectRoot, "node_modules"),
  path.resolve(workspaceRoot, "node_modules"),
];
// 3. Force Metro to resolve (sub)dependencies only from the `nodeModulesPaths`
config.resolver.disableHierarchicalLookup = true;

module.exports = config;

[bfricka]

FWIW, I have a very similar setup to yours, but do not use Expo and everything works. My watchFolders is a bit different, since I specify the root node_modules and then the sub-packages I want metro to be aware of (rather than the whole root folder). I also don't define nodeModulesPaths at all.

[jrosmith]

Closing this issue as this project ended up not using any native implementations. I ran into a similar issue with another section of the monorepo which is evidence that the issue was not with the metro bundler.

If anyone else runs into an issue similar to this - the problem is likely with the bundling of packages in your packages/ folder. The solution is going to be highly dependent on your setup.

In general, we ended up using tsup to build our modules with the most basic tsconfig.js and it solved our issues.