feat(exports): Add support for react-native conditional exports

[xgtz421]

In the exports field of package.json, a react-native conditional export has been added for the "." entry, pointing to ./modules/index.d.ts (types) and ./tslib.es6.mjs (default).

[jakebailey]

Why is this necessary?

[xgtz421]

English

Thank you for the question! This PR addresses a critical issue in React Native 0.84+ where the Metro bundler's new package resolution logic breaks backward
compatibility with tslib.

The Problem:

• In RN 0.84, Metro now respects the exports field in package.json by default (unstable_enablePackageExports: true)
• tslib's package.json defines export conditions but does NOT include a react-native condition
• When Metro tries to resolve tslib for React Native, it matches conditions in this order:
  • module → ❌ not matched
  • import → ❌ not matched
  • default → ✅ matched (falls back to CommonJS version)
• The Hermes engine in newer RN versions fails to parse __extends and other helper functions from the CommonJS version, causing runtime crashes

Why not just disable unstable_enablePackageExports?

• This is the future direction for RN and many modern libraries only define exports via the exports field
• Disabling it would create other compatibility issues and only delays the problem

The Solution:
This PR adds a react-native condition to tslib's exports, allowing Metro to correctly resolve the ESM version, which Hermes can properly handle.

---

中文

感谢提问！这个 PR 解决了 React Native 0.84+ 中一个关键的向后兼容性问题——Metro bundler 的新包解析逻辑破坏了对 tslib 的支持。

问题描述：

• 在 RN 0.84 中，Metro 现在默认遵循 package.json 中的 exports 字段（unstable_enablePackageExports: true）
• tslib 的 package.json 中定义了导出条件，但没有提供 react-native 条件
• 当 Metro 尝试为 React Native 解析 tslib 时，按以下顺序匹配条件：
  • module → ❌ 不匹配
  • import → ❌ 不匹配
  • default → ✅ 匹配（回退到 CommonJS 版本）
• 新版本 RN 的 Hermes 引擎无法从 CommonJS 版本中正确解析 __extends 等辅助函数，导致运行时崩溃

为什么不直接禁用 unstable_enablePackageExports？

• 这是 RN 的发展方向，越来越多现代库只通过 exports 字段定义入口点
• 禁用它会产生其他兼容性问题，只是延迟了问题的出现

[jakebailey]

I don't understand why this is a problem with tslib. It seems very much like this bundler's fault for not supporting something. It doesn't make sense that every lib that it isn't compatible with needs to special-case react-native.

[xgtz421]

You're right — this is not a tslib issue. The root cause is that Metro bundler doesn't enable the "import" condition by default when resolving package exports, so it falls back to the CJS entry. Under Hermes's ESM interop, the named exports then become undefined.

I've worked around this on our side by redirecting tslib to tslib.es6.mjs in our Metro config. Sorry for the noise, and thanks for taking the time to explain.
Closing this PR.