pnpm: [bug] - Pnpm not working with expo

@byCedric now that Expo SDK 50 uses React Native 0.73 (which made the Metro symlinks support stable, which has been reported as working by the community without Expo), would it be considered a bug in Expo for pnpm support to not work out of the box (without node-linker=hoisted or any other workarounds) with a new create-expo app?

• https://github.com/expo/expo/issues/22413#issuecomment-1913169577

The way I understand it, the work involved on Expo’s side for supporting symlinks would be refactoring the following:

• relative paths from files within node_modules
• any other code that relies on a fixed node_modules structure

Would be great to be able to use Expo + the new Metro symlink support without the node-linker=hoisted workaround!

@zkochan alternatively, if Expo will not do the work above to support symlinks, would pnpm consider adopting into core some public-hoist-pattern[] hoisting exceptions config for Expo and related packages which rely on a fixed node_modules directory structure?

Some users have reported public-hoist-pattern[] configurations working for them:

• https://github.com/nrwl/nx-labs/issues/34#issuecomment-1241922589
• https://github.com/evelant/test-pnpm-ios-headers-path-bug/blob/main/.npmrc

eg. the following (not tested as working yet)

public-hoist-pattern[]=*expo*
public-hoist-pattern[]=*react-native-gradle-plugin*
public-hoist-pattern[]=*@react-native-community/cli-platform-android*
public-hoist-pattern[]=*@react-native-community/cli-platform-ios*

I know that pnpm already has some public-hoist-pattern[] configuration in core for some other popular packages in the ecosystem which also rely on node_modules directory structure - so I’m asking whether pnpm would also consider this for Expo, if they will not do the work to refactor.

That’s not an issue related to pnpm, or Expo. It’s just how Metro explains it can’t find packages. I got it working with the --shamefully-hoist flag, and going over the steps in Working with Monorepos, in case it helps. https://github.com/byCedric/eas-monorepo-example/pull/19

Thanks. I actually looked into that just now and these are the specific changes necessary for pnpm: https://github.com/rhyek/expo-monorepo-issue/compare/pnpm...pnpm-fixed

It works this way, but isn’t it contrary to the principle of operation of pnpm? The purpose of pnpm is to use symlinks to reduce the size of node_modules, isn’t it?

@wesleyfreit @watadarkstar these two configurations are not following my suggested public-hoist-pattern[]= config above:

1. Your config above includes Babel, ESLint and Prettier dependencies, which are unrelated to React Native / Expo hoisting problems
2. Your config above uses node-linker=hoisted, which is a workaround for the issue and avoids the problem which should actually be fixed by Expo / React Native / pnpm (description on option: “A React Native project will most probably only work if you use a hoisted node_modules.”)

The point of issues like this are to try to move past the historical limitation of React Native to not work with symlinks and pnpm’s default isolated linker, now that Expo SDK 50 uses React Native 0.73, which made the Metro symlinks support stable:

• https://github.com/pnpm/pnpm/issues/4286#issuecomment-1913173223

Yes, @karlhorky is correctly, my project is working good using public-hoist-pattern[] pnpm configuration in .npmrc and other configurations in metro.config.js.

I’m using a default expo project created inside the monorepo using turborepo with pnpm.

My .npmrc:

public-hoist-pattern[] = @babel/*
public-hoist-pattern[] = *eslint* // if you use eslint
public-hoist-pattern[] = *prettier* // if you use prettier

In my expo project, I have the @rnx-kit/metro-resolver-symlinks package installed.

And my metro.config.js:

const { getDefaultConfig } = require('expo/metro-config');
const MetroSymlinksResolver = require('@rnx-kit/metro-resolver-symlinks');
const path = require('path');

// Find the workspace root
const workspaceRoot = path.resolve(__dirname, '../..');
const projectRoot = __dirname;

const config = getDefaultConfig(projectRoot);

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

// Let Metro know where to resolve packages, and in what order
config.resolver.nodeModulesPaths = [
  path.resolve(projectRoot, 'node_modules'),
  path.resolve(workspaceRoot, 'node_modules'),
];

// Force Metro to resolve (sub)dependencies only from the `nodeModulesPaths`
config.resolver.disableHierarchicalLookup = true;

// Using the Metro Symlinks Resolver config of the `rnx-kit`
config.resolver.resolveRequest = MetroSymlinksResolver();

module.exports = config;

In my project, the typescript path mapping configuration (ex: @/), did not work with the described configuration, so I had to remove it. Maybe I should add another public pattern for typescript, but I preferred not to add it.

Right. But we can’t fix issues in third party libs. The global store is still used. Even with hoisted linker

Try with the node-linker=hoisted option https://pnpm.io/npmrc#node-linker