Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Support RN SDK use in libraries

Open
  • Is something wrong?
#4,377 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
25/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Stale
Tech stack
javascript, react-native
Domain
mobile, observability

Research direction

Start by reproducing the issue with React Native 0.71.11, Hermes, Metro, and Sentry React Native SDK 6.2.0 on Android and iOS, using the Sentry.init beforeSend callback and the sample stacktrace. Trace how stacktrace.frames filenames are produced and define done as a reliable library/client distinction or a documented limitation and alternative.

Written by the indexing model from the issue text.

Description

Errors Feature React-Native
What React Native libraries do you use?

React Native without Frameworks

Are you using sentry.io or on-premise?

sentry.io (SaS)

@sentry/react-native SDK Version

6.2.0

How does your development environment look like?

Sentry React Native SDK Version: 6.2.0
React Native Version: 0.71.11
Hermes Enabled: Yes
Platforms Tested: Android, iOS
Build Tools: Metro bundler

Sentry.init()
Sentry.init({
  dsn: 'https://[email protected]/library-project-id',
  release: '0.0.1',
  beforeSend(event) {
    // Attempting to filter errors based on stacktrace
    const isFromLibrary = event.exception?.values?.some((value) =>
      value.stacktrace?.frames?.some((frame) =>
        frame.filename?.includes('/node_modules/@my-library-name')
      )
    );

    return isFromLibrary ? event : null;
  },
});
Steps to Reproduce

I am unable to effectively filter errors in my React Native project using stacktrace.frames in the beforeSend callback. Despite providing proper logic to inspect the stack trace and filenames, the error events do not include sufficient information to reliably distinguish between errors originating from my project( my project is react native library ) and those from the client app.

This has become a critical issue for my project, where I am building a React Native SDK that will be integrated into client apps. I want to ensure that only errors from my SDK are sent to my Sentry project, while unexpected errors from client apps (using their own DSN and release) are excluded.

Expected Result
  • I expect the stacktrace.frames[].filename to include the library name or a clear identifier (e.g., node_modules/@my-library or similar) that shows where the error originates. This would make it much easier to filter errors specific to the project.
  • If this is not posible, is there another reliable way to distinguish between errors originating from the library and client app without relying solely on the stacktrace? Thanks
Actual Result

Stacktrace Does Not Contain library Identifiers:

The stacktrace.frames[].filename does not include a clear path to node_modules/@my/library-name or any other library-specific identifier.
Example stacktrace from a client app error:

"stacktrace": {
  "frames": [
    {
      "filename": "app:///Pressability.js",
      "function": "responderEventHandlers.onResponderRelease",
      "lineno": 525,
      "colno": 27
    },
    {
      "filename": "app:///index.js",
      "function": "TouchableOpacity.props.onPress",
      "lineno": 171,
      "colno": 27
    }
  ]
}
Dominant language
TypeScript
Stars
1.8k
Forks
369
Avg merge
20h 53m
Merged PRs (30d)
103

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from getsentry/sentry-react-native

All issues in getsentry/sentry-react-native

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.