You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
react-native core also has some more configuration flags that are hidden in native side (ex. turning on Hermes and the new arch are in iOS's podfile and Android's gradle file)
where do we want to be
lib maintainers have a way to declare support for the new arch
we can use align-deps and rn-directory to surface that information to the developers
we need a 3 lights semaphore:
🔴 = no support for new arch at all
🟡 = we can infer that it will probably work with the new arch based on. For example, we could use the same one that RNDirectory uses, based on the presence of the codegenConfig field in package.json
🟢 = library has our custom-setting field set to true
How can we get there?
proposal 1: define a react-native-config section of package.json that is spec'd and is coherent with existing config approach (should 1:1 having a react-native.config.js/app.config.js) with a dedicated field for declaring new arch support
the reason why we need it in the package.json is that it makes it easier/faster to read (especially for rn-directory, no need to download the entire thing)
doesn't solve the flags for app configuration (ex. hermes, new arch)
doesn't mention iOS/Android specificities
even the semaphore doesn't cover new arch only / not backward compat case
react-native-library section would be a much better name
react-native-metadata / react-native-meta is another broader alternative that would allow to keep everything within it and could potentially work along a future also react-native-config
reactNativeMeta looks like a winner
do we need to version it? (similarly to how CIs do it)
codegen changes so we should have a way to tell which version of codegen it's working against
let's use more specific keys like TurboModules and/or Fabric?
Action items
@kelset RFC with first draft of the final idea reactNativeMeta so that we can async fill the details of the specific fields
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Agenda notes
Where are we today
align-deps
Use align-deps to help migrate apps to the New Architecture #1863react-native.config.js
https://github.com/react-native-community/cli/blob/main/docs/configuration.md#configurationapp.json
/app.config.js
https://docs.expo.dev/workflow/configuration/app.json
used in non Expo-projects? RNTA?expo-module.config.json
(https://docs.expo.dev/modules/autolinking/)app.json
https://github.com/microsoft/react-native-test-app/wiki/Manifest-(app.json)codegenConfig
where do we want to be
🔴 = no support for new arch at all
🟡 = we can infer that it will probably work with the new arch based on. For example, we could use the same one that RNDirectory uses, based on the presence of the codegenConfig field in package.json
🟢 = library has our custom-setting field set to true
How can we get there?
react-native-config
section of package.json that is spec'd and is coherent with existing config approach (should 1:1 having areact-native.config.js
/app.config.js
) with a dedicated field for declaring new arch supportapp.json
entirely while at it?Let's discuss!
react-native-library
section would be a much better namereact-native-metadata
/react-native-meta
is another broader alternative that would allow to keep everything within it and could potentially work along a future alsoreact-native-config
reactNativeMeta
looks like a winnerAction items
reactNativeMeta
so that we can async fill the details of the specific fieldsBeta Was this translation helpful? Give feedback.
All reactions