Feature Request: Add "New Arch Introduced In" Field for Bettter Compatibility Tracking

[dengel29]

Currently, tools like expo-doctor use React Native Directory to check for New Architecture (Fabric) compatibility. However, the existing flags ("newArch": true/false) are binary and don't capture the nuance of which version of a library introduced New Architecture support.

This leads to a situation where a developer can be using a version of a library that does not support the New Architecture, while a newer version does. expo-doctor may not flag this, because the directory simply marks the library as compatible ("newArch": true), without any version context.

For example, our project is using @intercom/intercom-react-native: ^8.1.0 with the New Architecture enabled. This version is not compatible, but because a later version (9.0.0-beta.2) is compatible, the directory doesn't catch the issue. This results in potential runtime errors that are difficult to diagnose.

Describe the solution you'd like

I propose adding a new, optional field to the react-native-libraries.json schema: newArchIntroducedIn.

This field would be a string representing the semantic version number where New Architecture support was first introduced.

Example of the proposed JSON structure change:

{
  "githubUrl": "https://github.com/intercom/intercom-react-native",
  "ios": true,
  "android": true,
  "expoGo": false,
  "web": false,
  "windows": false,
  "macos": false,
  "newArch": true,
  "newArchIntroducedIn": "9.0.0-beta.2", // <-- Proposed new field
  "npmPkg": "@intercom/intercom-react-native",
  "unmaintained": false
  // ... rest of the fields
}

Describe alternatives you've considered

The alternative is to manually track this information, which is what we are currently doing. We've used package.json's resolutions field to enforce a minimum version, but this is a project-specific workaround and doesn't solve the problem for the wider community.

Additional context

By adding this field, tooling like expo-doctor could be updated to perform more intelligent checks. For example, it could compare the version specified in a project's package.json against the newArchIntroducedIn value. If the project's version is lower, it could provide a specific, actionable warning:

"Warning: @intercom/intercom-react-native supports the New Architecture starting from version 9.0.0-beta.2, but your project is using 8.1.0."

This would be a massive improvement to the developer experience and would make the transition to the New Architecture much smoother for the entire community.

Thank you for considering this proposal!

[Simek]

Hey @dengel29, thanks for the feedback and writing up a proposition! 👍

We already have a newArchitectureNote field which can be used to provide an additional information about New Architecture support by package authors. It's a string field, so various information can be included in there.

Some authors already use that field in the version support context, i.e:

• https://github.com/react-native-community/directory/blob/main/react-native-libraries.json#L4603
• https://github.com/react-native-community/directory/blob/main/react-native-libraries.json#L10282

Unfortunately, the biggest problem here is that we don't know the extract version or date when New Architecture has been added for each of 2k+ package and we cannot extract this information easily in an automated way, so responsibility for providing this information is mostly on the package authors side, or contributions from the users/community, no matter if we stick to current field or introduce a new one.

However, if expo-doctor does not print the current note we definitely should add it!

Few more end notes:

• when it comes to the New Architecture support, this field probably would be removed in the future, when New Architecture is the only architecture avaible, and there is no way to use the old one. All packages which does not support it at that date, would be automatically marked as unmaintained.
• extracting packages resolutions unfortunately is not the solution because majority of packages use wildcard versions (*) which does not covey the information or required minimum React Native version, but even when it's filled New Architecture support is only loosely connect with New Architecture support, and unfortunately there is no custom field in package.json schema which would allow package developers to provide that information.