sentry-react-native icon indicating copy to clipboard operation
sentry-react-native copied to clipboard

CLI incorrectly resolves path to the Metro config in a NX monorepo

Open skoob13 opened this issue 2 years ago • 7 comments

OS:

  • [ ] Windows
  • [X] MacOS
  • [ ] Linux

Platform:

  • [X] iOS
  • [ ] Android

SDK:

  • [X] @sentry/react-native (>= 1.0.0)
  • [ ] react-native-sentry (<= 0.43.2)

SDK version: 5.1.0

react-native version: 0.71.4

Are you using Expo?

  • [ ] Yes
  • [X] No

Are you using sentry.io or on-premise?

  • [X] sentry.io (SaaS)
  • [ ] on-premise

Configuration:

I used the default configuration from Sentry Wizard.


I have following issue:

When Sentry modifies the "Bundle React Native code and images" in the Xcode project, Xcode fails to build because Sentry's CLI modifies cwd in the RN's build script and sets it to the root of a monorepo. Furthermore, RN's CLI fails to load metro.config.js from the package in a monorepo because cwd is getting resolved to the root of a NX monorepo when the default script resolves a package's path correctly.

Consider following structure in a NX monorepo:

  • packages
    • mobile (react-native app)
    • lib1 (react native shared lib)

When the default build script is used, then the path in logs of the phase is <root>/packages/mobile. However, when I use the Sentry's build script, Sentry's CLI sets the path to <root>.

NX creates a symlinked node_modules folder from the root in the React Native's package, e.g. packages/mobile/node_modules. Presumably, Sentry's CLI incorrectly resolves the symlinked path.

Steps to reproduce:

  • Clone the repo
  • Install dependencies (yarn was used)
  • Verify that the RN's script resolves the metro.config.js path correctly using the command yarn nx run test:start. It will launch the packager and you'll see the config loaded line, which is a console.log statement in the packages/test/metro.config.js.
  • Build the xcode project. I was using Archive and the Release scheme. When build fails, open the build log and notice that there isn't the config loaded line.

Modifying the RN's CLI module could also help to debug. I logged in console ctx.root in order to get the resolved path.

Actual result:

Path is set to <root>

Expected result:

Path should be set to <root>/packages/mobile.

skoob13 avatar Mar 09 '23 16:03 skoob13

Thank you for the detailed info and the example repo. We will take a look at this.

krystofwoldrich avatar Mar 10 '23 11:03 krystofwoldrich

Are there any solutions or workarounds? Having struggle to solve this issue in our nx repo. The build phase script fails, because it cannot find the other libs. I think this is because the metro.config with the aliases is not loaded

Blackfaded avatar Jun 16 '23 14:06 Blackfaded

Fixed it with

export PROJECT_ROOT=".."

In the Bundle React Phase 🚀

Blackfaded avatar Jun 16 '23 15:06 Blackfaded

@Blackfaded I removed the Sentry's build script and fixed the build step to upload source map files manually.

Modified build phase "Bundle React Native code and images" (xcode project):

set -e

export SOURCEMAP_FILE="$(pwd)/../../../dist/apps/mobile/main.jsbundle.map";

DIST_OUTPUT_PATH="$(pwd)/../../../dist/apps/mobile"
mkdir -p $DIST_OUTPUT_PATH

WITH_ENVIRONMENT="../node_modules/react-native/scripts/xcode/with-environment.sh"
REACT_NATIVE_XCODE="../node_modules/react-native/scripts/react-native-xcode.sh"

/bin/sh -c "$WITH_ENVIRONMENT $REACT_NATIVE_XCODE"

BUNDLE_PATH="$CONFIGURATION_BUILD_DIR/main.jsbundle"

if [ -e $BUNDLE_PATH ]
then
    cp $BUNDLE_PATH "$DIST_OUTPUT_PATH/main.jsbundle"
fi

After the build, the Sentry's fastlane action picks up a bundle and a source map and uploads.

skoob13 avatar Jun 16 '23 15:06 skoob13

@skoob13 Thank you for the repro.

I can confirm export PROJECT_ROOT=".." in the build phase is a good tmp workaround for the issue. Thank you @Blackfaded.

Link to updated repro to build with Xcode 14.2 and newer https://github.com/krystofwoldrich/sentry-nx-rn-bug/tree/5dd84fd28e2d73b23903601bfdef8d4399f9161e

krystofwoldrich avatar Jun 19 '23 13:06 krystofwoldrich

@krystofwoldrich is this still relevant / is the workaround good enough?

kahest avatar Mar 10 '25 18:03 kahest

The workaround is okay temporarily, but the issue is still relevant.

krystofwoldrich avatar Apr 11 '25 15:04 krystofwoldrich