Notes for meeting about react-native field in package.json

= 0.71.0", "expo": ">= 46.0.0", "expo-modules-core": "1.2.0" } ... } }"> = 0.71.0", "expo": ">= 46.0.0", "expo-modules-core": "1.2.0" } ... } }"> = 0.71.0", "expo": ">= 46.0.0", "expo-modules-core": "1.2.0" } ... } }">

{
  "react-native-config": {
    "features": {
      "newArchitecture": ......,
    },
    "requirements": {
      "react-native": ">= 0.71.0",
      "expo": ">= 46.0.0",
      "expo-modules-core": "1.2.0"
    }
		...
  }
}

react-native-config field should be used in libraries by library authors and not in app package.json - so maybe we could call it react-native-module or something?
- Proposal: Put metadata in here, don't migrate anything off of other configs yet (and maybe not ever)
  - Metadata that other tools can read and decide what to do with it
  - The requirements field (note: intentionally not "peer dependencies" $^1$, but the name is very open for alternatives) solves this problem we encountered on React Native Directory
- app.json is only used in apps, not in libraries. react-native.config.js is used in both
- expo-module.config.json → Expo Autolinking Config for a library
- "expo" field in package.json is used for configuring autolinking
- react-native.config.js is used for configuring React Native Community CLI
  - For your own project - you can tell React Native Community CLI not to link certain packages or configure autolinking in other ways
  - For libraries - configure autolinking for that library
  - react-native.config.js not static so we can't easily scrape it in React Native Directory, similar to app.json / app.config.js

$^1$ The topic of peerDependencies is also complicated by:

npm / yarn differences (npm 7 auto install)
Tree flattening algorithms for npm / yarn / workspaces