react-native-community / cli Goto Github PK

Xcode can connect and run apps on devices that are connected with wifi. It would be very useful to be able to run react-native run-ios --device and the app runs on a device that's connected with wifi, and not necessarily with a cable to Xcode.

I can try to make this happen. Is that alright? Would this be accepted?

Recent commit updated Android part of the link mechanism to use "implementation" instead of "compile" to align with what Gradle recommends: c6c34a2

Unfortunately, it breaks the detection of an already installed packages.

The way "link" detects an installed package on Android is by looking for "compile(XXX)" inside build.gradle. We don't have a sophisticated tool for parsing and reading Gradle files, hence we use a really simple RegExp to look for informations that we want. It was always meant to be a temporary solution, so we are going to work on resolving that in the nearest future.

Meanwhile, what happens is that now, after the update, "link" will look for "implementation(XXX)" string instead to indicate that the given package is already linked.

This means that when "link" command is run on an existing codebase that still uses "compile" (e.g. just updated to a new project), it will not treat such project as installed and will add it once again, this time using implementation(XXX). This results with duplicate packages.

We should teach link/android/isInstalled.js to return "true" in both scenarios when "compile" and "implementation" are present. Both are valid right now in Gradle v3 (with "compile" being obsolete).

We should also make sure that "unlink" can handle both cases.

CC: @thymikee @dulmandakh (original reviewer of the PR)

There are flow issues in the repository that we were ignoring for a while. Opening this issue to keep track of them and work towards fixing them.

We should add issue and PR templates to meet community standards. It should be something simmilar to https://github.com/facebook/react-native/tree/master/.github .

We don't need a whole bunch of React Native-specific presets to be loaded. We can use a simple babel-register with babel-preset-env to determine a subset of transforms to run based on the current Node environment.

That should help us improve startup time and remove lots of code to support Jest tests (including fbjs-scripts package).

The CLI experience is very raw. We should analyse what other CLI tools do in that space (Yarn, Jest and more - suggestions are welcome) and try to come up with our plan.

I've been working quite heavily on Haul where we did a "Create React App" - like interface that takes up the whole available space and cleans up the terminal when e.g. the build finishes.

I am leave this issue here open for discussion - would love to gather some ideas before we get started.

Migrated from React Native:
facebook/react-native#22022

The template can now be found in the root of react-native here: https://github.com/facebook/react-native/tree/master/template

Using the template from RN will allow us to keep the template in sync with RN, and it will allow the CLI to work with different versions of RN. If we do not use the template from the RN repo, the CLI repo will need to maintain the template for each version of RN it supports.

It has hardcoded paths to "react-native" (old CLI location).

Update: https://github.com/react-native-community/react-native-cli/blob/5d76ac9dcffa9cd5daa7e24bcd377b20e728faef/packages/global-cli/index.js#L64-L66 and https://github.com/react-native-community/react-native-cli/blob/5d76ac9dcffa9cd5daa7e24bcd377b20e728faef/packages/global-cli/index.js#L240-L249 to point to a new location.

Once this happens, we can remove "local-cli/cli.js" from React Native repository. Meanwhile, let's put a warning that developers should not call the CLI this way.

Migrated from React Native repo
facebook/react-native#22162

Let's say you have more than 1 app in your android directory. When you do:

react-native run-android --appFolder someAppFolder

It is installing all apps. This is because under the hood the cli is running ./gradlew installDebug. (or whatever variant). Instead it should be:

./gradlew :someAppFolder:installDebug

There's no need to validate React Native's package.json on client-side. This should be an error before we even publish React Native (or removed at all as it sounds like a fundamental feature of React Native).

Throwing this during runtime has no point.

https://github.com/react-native-community/react-native-cli/blob/a56441021f6455b61f353fcb137d17c86ccc0043/packages/cli/src/commands/init/init.js#L54-L67

Right now, CLI uses its own "templates/HelloWorld". This folder should be removed entirely and we should use the "HelloWorld" template bundled with React Native.

Introduction

A way to verify react-native installation is complete and working?

The Core of It

I was just checking out Flutter & I see there is a thing there called flutter doctor which ensures that installation is complete & working. I think it makes sense for React Native to have something like a react-native doctor or react-native health or something else.

Discussion points

Might be beneficial for beginners who have a lot of trouble installing Android Studio if they are on anything else than a Mac

Example of Flutter Doctor

Here's an output of the command flutter doctor -v in the terminal -

[✓] Flutter (Channel master, v1.1.2-pre.39, on Mac OS X 10.14.1 18B75, locale en-IN)
    • Flutter version 1.1.2-pre.39 at /Volumes/Coding/Code/Flutter/installation/flutter
    • Framework revision 0e9ad43416 (34 hours ago), 2018-12-16 16:39:28 -0500
    • Engine revision 4941125829
    • Dart version 2.2.0 (build 2.2.0-dev.1.1 f9ebf21297)

[✓] Android toolchain - develop for Android devices (Android SDK 28.0.3)
    • Android SDK at /Users/deadcoder0904/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-27, build-tools 28.0.3
    • ANDROID_HOME = /Users/deadcoder0904/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1136-b06)
    • All Android licenses accepted.

[✓] iOS toolchain - develop for iOS devices (Xcode 10.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 10.1, Build version 10B61
    • ios-deploy 1.9.4
    • CocoaPods version 1.5.3

[✓] Android Studio (version 3.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 31.1.1
    • Dart plugin version 181.5656
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1136-b06)

[✓] VS Code (version 1.30.0)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 2.21.1

[!] Connected device
    ! No devices available

! Doctor found issues in 1 category.

This issue has been moved from react-native-community/discussions-and-proposals#73

We need Babel because there are Flow types inside.

We should consider the following:

• convert the whole project to Typescript
• pre-compile the CLI before publishing to npm to speed up the start-up time (which is extremely slow right now)

I guess we can start with the latter and consider doing the former at some point. I am also a big supporter of ReasonML and would love seeing parts of the CLI being written in it.

CC: @Esemesek

Right now it has its own detection mechanism for ios files. Should use the config that already does that job.

Like add util wait for emulator online. Make it easier for android to do instrumentation test.

I found this bug in React Native v0.57 and even though the Metro config handling in react-native start has changed a bit since then, it looks like this bug exists in react-native-local-cli as well.

It seems that we need to handle assetExts here, the same way sourceExts are handled: https://github.com/react-native-community/react-native-cli/blob/6de63fed2c931ba15296b3d51d85332030d741fd/packages/local-cli/server/runServer.js#L55

This also benefit for user easily set up ci.

• add debug sig by default
• make release sig more easily.

Waiting for the detailed write-up from @thymikee on this one.

There are 3 unit tests that are disabled for historical reasons. Unfortunately. I don't really remember what was the original reason.

Let's re-enable them (might need some little adjustments).

Migrated from RN core: facebook/react-native#22914

This issue covers points 2 and 3 from the React Native issue posted above.

The project does not run. After building the project and attempting to run the project on a connected device and that fails because it's looking for the APK file in the wrong place, e.g. react-native run-android --deviceId results in the following:
adb: failed to stat app/build/outputs/apk/app-debug.apk: No such file or directory
Command failed: /usr/local/share/android-sdk/platform-tools/adb -s 99523a0828712a92 install app/build/outputs/apk/app-debug.apk
Could not install the app on the device, read the error above for details.

This is because the APK builds to apk/debug/app-debug.apk, not apk/app-debug.apk!!!

I even tried explicitly adding the --variant debug flag and it still insists on looking for the APK in the parent folder (instead of in the "debug" child folder where the APK was built to).

Something like react-native link --assets ? Right now I cannot find a way to do this and it's not good in my project to run the whole react-native link.

Another interesting stuff is that you can run react-native link anyPackage and it will also link all the assets too. Is that desirable ?

Create "Contributing.md" and describe our testing process and how to contribute to the project.

CC: @Esemesek, based on our findings, most likely

I encountered an issue with a test project that uses RN built from source. For some reason I need to patch getProjectRoot inside node_modules/react-native-local-cli/util/Config.js to go up one more directory. Since the file resides in <APP_ROOT>/node_modules/react-native-local-cli/util the default ../.. results in packager looking for the app files inside <APP_ROOT>/node_modules not in <APP_ROOT>.

This might not be an issue anymore with master version of react-native-local-cli since the file has been removed and I failed to find the new location of that code. However, I tested both alpha.4 and alpha.5 and they behave a bit differently:

1.0.0-alpha.4

$ yarn start
yarn run v1.10.1
$ node node_modules/react-native/local-cli/cli.js start
┌──────────────────────────────────────────────────────────────────────────────┐
│                                                                              │
│  Running Metro Bundler on port 8081.                                         │
│                                                                              │
│  Keep Metro running while developing on any JS projects. Feel free to        │
│  close this tab and run your own Metro instance if you prefer.               │
│                                                                              │
│  https://github.com/facebook/react-native                                    │
│                                                                              │
└──────────────────────────────────────────────────────────────────────────────┘

Looking for JS files in
   /Users/Me/projects/rn-geoloctest/node_modules

1.0.0-alpha.5

$ yarn start
yarn run v1.10.1
$ node node_modules/react-native/local-cli/cli.js start
┌──────────────────────────────────────────────────────────────────────────────┐
│                                                                              │
│  Running Metro Bundler on port 8081.                                         │
│                                                                              │
│  Keep Metro running while developing on any JS projects. Feel free to        │
│  close this tab and run your own Metro instance if you prefer.               │
│                                                                              │
│  https://github.com/facebook/react-native                                    │
│                                                                              │
└──────────────────────────────────────────────────────────────────────────────┘

Looking for JS files in
   /Users/Me/projects/rn-geoloctest/node_modules/react-native

Adding support for Kotlin based Android projects.

Link could detect if project is Java/Kotlin based and act accordingly.

Environment

React Native Environment Info:
System:
OS: macOS 10.14.1
CPU: (4) x64 Intel(R) Core(TM) i5-4570R CPU @ 2.70GHz
Memory: 28.95 MB / 16.00 GB
Shell: 3.2.57 - /bin/bash
Binaries:
Node: 8.12.0 - /usr/local/opt/node@8/bin/node
Yarn: 1.12.3 - /usr/local/bin/yarn
npm: 6.4.1 - /usr/local/opt/node@8/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
SDKs:
iOS SDK:
Platforms: iOS 12.1, macOS 10.14, tvOS 12.1, watchOS 5.1
Android SDK:
API Levels: 23, 25, 26, 27, 28
Build Tools: 23.0.1, 23.0.2, 25.0.0, 25.0.1, 25.0.2, 26.0.2, 26.0.3, 27.0.3, 28.0.2, 28.0.3
System Images: android-23 | Google APIs Intel x86 Atom, android-27 | Google APIs Intel x86 Atom, android-27 | Google Play Intel x86 Atom
IDEs:
Android Studio: 3.2 AI-181.5540.7.32.5014246
Xcode: 10.1/10B61 - /usr/bin/xcodebuild
npmPackages:
react: 16.6.1 => 16.6.1
react-native: 0.57.7 => 0.57.7

Description

When I run iOS on Xcode with Release scheme, the metro bundler started even though it's not using it .

Reproducible Demo

$ git clone [email protected]:james1888/rnmetrobug.git
$ cd rnmetrobug
$ yarn start
$ react-native run-ios --configuration Release 

Opening this issue to discuss the naming strategy for packages included in this repository in the npm registry.

Right now, there's this concept of a global CLI. It's meant to be installed only once and rarely updated. It's a single file that does two things:

• it installs react-native from npm registry and uses local-cli bundled with it to init a new project
• it proxies all calls to node_modules/react-native/local-cli/cli.js when run in context of a React Native project

Ultimately, I would like to deprecate the second use-case now that we can just do yarn react-native and execute the node_modules CLI automatically.

Because the react-native-cli name is already taken by the global CLI, it makes it tricky to find a good name for the local-cli, that is, the real CLI where all the tools and commands are located.

react-native-local-cli is not much descriptive as pointed out by @cpojer and closes the door to modify the structure in the future. If we ever deprecate react-native-cli (global one) in favour or more user-friendly tools, the react-native-local-cli will make no sense to people that didn't remember it living in the React Native repository or having the global package.

Other ideas are react-native-scripts.

What do you think?

• Review the documentation: https://facebook.github.io/react-native
• Search for existing issues: https://github.com/facebook/react-native/issues
• Use the latest React Native release: https://github.com/facebook/react-native/releases

Environment

Run react-native info in your terminal and paste its contents here.

React Native Environment Info:
  System:
    OS: macOS 10.14.3
    CPU: (4) x64 Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
    Memory: 28.63 MB / 8.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 10.13.0 - ~/.nvm/versions/node/v10.13.0/bin/node
    Yarn: 1.12.3 - /usr/local/bin/yarn
    npm: 6.4.1 - ~/.nvm/versions/node/v10.13.0/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  SDKs:
    iOS SDK:
      Platforms: iOS 12.1, macOS 10.14, tvOS 12.1, watchOS 5.1
  IDEs:
    Android Studio: 3.2 AI-181.5540.7.32.5014246
    Xcode: 10.1/10O23u - /usr/bin/xcodebuild
  npmPackages:
    react: 16.6.3 => 16.6.3 
    react-native: 0.57.8 => 0.57.8

Description

Describe your issue in detail. Include screenshots if needed. If this is a regression, let us know.
If you add a custom target to your iOS project, the linking process just outright fails.

Cannot read property 'buildConfigurationList' of undefined

TypeError: Cannot read property 'buildConfigurationList' of undefined
    at ./node_modules/react-native/local-cli/link/ios/getTargets.js:18:68
    at Array.map (<anonymous>)
    at getTargets (./node_modules/react-native/local-cli/link/ios/getTargets.js:16:18)
    at registerNativeModuleIOS (./node_modules/react-native/local-cli/link/ios/registerNativeModule.js:52:19)
    at Object.registerNativeModule [as register] (./node_modules/react-native/local-cli/link/ios/common/registerNativeModule.js:15:5)
    at Object.keys.forEach.platform (./node_modules/react-native/local-cli/link/link.js:74:16)
    at Array.forEach (<anonymous>)
    at linkDependency (./node_modules/react-native/local-cli/link/link.js:44:32)

Reproducible Demo

Let us know how to reproduce the issue. Include a code sample, share a project, or share an app that reproduces the issue using https://snack.expo.io/. Please follow the guidelines for providing a MCVE: https://stackoverflow.com/help/mcve
Example at https://github.com/dotconnor/CustomTargets

• react-native init myproject
• Add a custom target in XCode, in my example i have a simple Aggregate target that updates my Info.plist with the correct version but it can just be left empty.
• yarn add react-native-svg or any other project that requires linking
• react-native link react-native-svg

In order to support different bundlers in the future (and also to clean up the codebase a bit), we should make a separate package for the server command. That would allow us prepare for decoupling in the future, but also to further decouple CLI from Metro where it doesn't need to use it.

See: https://stackoverflow.com/questions/49851602/how-do-i-exclude-a-package-from-react-native-link

I think this will be useful (and maybe even necessary if some libraries break).

This is a meta issue to keep track of the things that need to be tweaked to give RN-CLI support for Yarn Plug 'n Play. This is probably non-exhaustive, more things might be found as others are tweaked.

• Global CLI: Support for finding react-native and react-native-local-cli when PnP is enabled (in progress: #26 )

• react-native bundle: Support for bundling dependencies with PnP. (Metro team is working on open sourcing its PnP support: facebook/metro#308)

• findPlugins: Plugin discovery code will need to be adapted to support PnP

• Xcode pbxproj files all have paths hardcoded in like this:

  path = "../node_modules/react-native/React/React.xcodeproj";

  There is, as far as I know, no way to have this path be dynamic. Ideally there would be some kind of way to have Xcode call a subprocess (like node resolve-dependency.js or something) and use it as the path's prefix, but I don't think there's a way. So I think a script might need to be made to refresh these paths and keep them up to date.

  This is also relevant for user libraries and react-native link for iOS dependencies

• Gradle scripts will need to be updated along with react-native link's Gradle output. Here's an example bit out output for react-native-webview:

  project(':react-native-webview').projectDir = new File(rootProject.projectDir, '../node_modules/react-native-webview/android')

  The path to it is hardcoded to look in node_modules. I think a new helper function could be written, that would look something like:

  npm_dependency('react-native-webview', 'android')

  Where the first argument is the name of the node module, and the second is a pathname within the node_module. If PnP isn't present, then it will simply output an old-style path to node_modules. A similar function could be made for BUCK.

• Paths to node_modules/react-native are hardcoded in these files and will need to be updated. They could all use util/findReactNativePath, potentially.

  • local-cli/library/library.js
  • local-cli/eject/eject.js
  • local-cli/generator/templates.js
  • local-cli/link/__tests__/ios/getHeaderSearchPath.spec.js
  • local-cli/upgrade/upgrade.js
  • local-cli/util/findReactNativeScripts.js

Looking for JS files in
D:\LW_Mobile\Projects\helloworld

Loading dependency graph, done.
error: bundling failed: Error: Unable to resolve module ./../../react-transform-hmr/lib/index.js from D:\LW_Mobile\Projects\helloworld\App.js: The module ./../../react-transform-hmr/lib/index.js could not be found from D:\LW_Mobile\Projects\helloworld\App.js. Indeed, none of these files exist:

• D:\LW_Mobile\react-transform-hmr\lib\index.js(.native||.android.js|.native.js|.js|.android.json|.native.json|.json|.android.ts|.native.ts|.ts|.android.tsx|.native.tsx|.tsx)
• D:\LW_Mobile\react-transform-hmr\lib\index.js\index(.native||.android.js|.native.js|.js|.android.json|.native.json|.json|.android.ts|.native.ts|.ts|.android.tsx|.native.tsx|.tsx)
  at ModuleResolver.resolveDependency (D:\LW_Mobile\Projects\helloworld\node_modules\metro\src\node-haste\DependencyGraph\ModuleResolution.js:209:697)
  at ResolutionRequest.resolveDependency (D:\LW_Mobile\Projects\helloworld\node_modules\metro\src\node-haste\DependencyGraph\ResolutionRequest.js:83:16)
  at DependencyGraph.resolveDependency (D:\LW_Mobile\Projects\helloworld\node_modules\metro\src\node-haste\DependencyGraph.js:222:485)
  at Object.resolve (D:\LW_Mobile\Projects\helloworld\node_modules\metro\src\lib\transformHelpers.js:149:25)
  at dependencies.map.result (D:\LW_Mobile\Projects\helloworld\node_modules\metro\src\DeltaBundler\traverseDependencies.js:316:29)
  at Array.map ()
  at resolveDependencies (D:\LW_Mobile\Projects\helloworld\node_modules\metro\src\DeltaBundler\traverseDependencies.js:312:16)
  at D:\LW_Mobile\Projects\helloworld\node_modules\metro\src\DeltaBundler\traverseDependencies.js:169:33
  at Generator.next ()
  at step (D:\LW_Mobile\Projects\helloworld\node_modules\metro\src\DeltaBundler\traverseDependencies.js:271:307)
  BUNDLE [android, dev] ....../index.js ░░░░░░░░░░░░░░░░ 5.5% (52/221), failed.

::ffff:127.0.0.1 - - [06/Oct/2018:17:30:21 +0000] "GET /index.delta?platform=android&dev=true&minify=false HTTP/1.1" 500 - "-" "okhttp/3.10.0"

Command
react-native run-android

Environment
npm: 6.4.1
node: v8.12.0
windows 10
yarn 1.10.1

Package.json
{
"name": "helloworld",
"version": "0.0.1",
"private": true,
"scripts": {
"start": "node node_modules/react-native/local-cli/cli.js start",
"test": "jest"
},
"dependencies": {
"@babel/runtime": "^7.1.2",
"babel-preset-react-native": "^4.0.0",
"react": "16.5.0",
"react-native": "0.57.2"
},
"devDependencies": {
"@babel/cli": "^7.1.2",
"@babel/core": "^7.1.2",
"babel-jest": "23.6.0",
"babel-plugin-functional-hmr": "^1.0.24",
"babel-plugin-react-transform": "^3.0.0",
"jest": "23.6.0",
"metro-react-native-babel-preset": "0.48.0",
"react-test-renderer": "16.5.0",
"react-transform-hmr": "^1.0.4"
},
"jest": {
"preset": "react-native"
}
}

babel.rc

{
"presets": ["module:metro-react-native-babel-preset"]
}

This is easy one.

After creating a "config.root" value and explicitly defining "projectRoot" flag for every command, we should make sure that all the commands use it, instead of "process.cwd()".

Otherwise, it may give unexpected errors during runtime.

How to go about implementing it?

1. Make sure that none of the commands define their own "--root" or something. If they do, remove it and replace occurrences of it with "ctx.root" (look at "link" as an example)

2. Make sure that no commands call "process.cwd()" themselves and replace as in the above.

The local-cli/core is not really a core, it's just a set of useful "tools" that can be used to locate iOS project somewhere etc.

In order to make it easy for other plugins and packages to use this, we should definitely make it a separate package with public interface.

Right now, some developers are requiring them directly from "build" or "src" folder, which is dangerous.

Using this issue to keep track of different things that have to happen in order for this to ship. Note that the list is not definitive and I expect some positions to be added over time.

• Work on the new file structure (possibly with Yarn workspaces)
• ...

When you don't pass a package name to the "react-native link", it will try to look for all packages to link from your node_modules.

This is causing us a lot of issues, such as linking wrong packages or the ones that someone doesn't want to link (e.g. decided to use a different way of linking that is out of scope for this command).

We should simply stick to requiring package name.

Since the introduction of the Cocoapods check in this PR, any project with a Podfile linking any library with .podspec will be linked by adding the library to the cocoapods. Although this is theoretically the desired behaviour and a much better way to link libraries, there are various reasons why some libraries need to be linked in the direct way instead. Most app projects require cocoapods for something during their lifecycle. After adding cocoapods, adding several high profile react native libraries becomes much more complicated. This is a proposal to address that.

With this issue I propose two things:

1. It should be possible for a library maintainer to indicate that the iOS native library should be linked directly to the app project, instead of through cocoapods, even with a Podfile available in the target. (eg. facebook/react-native#15460 (comment))
2. It should be possible for a linking target project to force react-native link to specify individual libraries to link directly through the project, instead of through the Podfile.

One example of why this would help is react-native-firebase, where their install for iOS documentation describes:

Firebase recommends using Cocoapods to install the Firebase SDK.

and the react-native-firebase

Option 1: Link React Native Firebase (Recommended)

Some related communication from @chrisbianca: invertase/react-native-firebase#838 facebook/react-native#15460 (comment)

Other scenarios where linking to Podfile is causing issues is react-native-config and react-native-branch.

If 1. is implemented, the library maintainers can resolve those issues for their users, by forcing link to ignore the Podfile and the libraries .podspec. 2. can be used by the consumers of those libraries to implement a stable workaround until the libraries in question have resolved it for them.

Just an additional link as to why this is important, here is a workaround posted to one of the issues which basically instructs the user to delete the Podfile, then run link, then add the Podfile again: lugg/react-native-config#187 (comment)
This shouldn't be necessary :)

Provide command line to make them easily integrate ci system.

CI file can check here https://github.com/react-native-community/ci-sample.

Related: facebook/react-native#22779.

Create package.json with all necessary dependencies inside local-cli package.

Right now we can do:

“rnpm”: {
   “assets”: [“./path to your fonts”]
}

What do you think of:

“rnpm”: {
   “assets”: {
      "android": [path to folders]
      "ios": [path to folders]
   }
}

In this way we won't link/copy assets that are not specific to one platform (like one font only used on iOS).

I am working on a bunch of upgrades and will need to write a changelog soon.

Here's list of things to include before we release it - has to happen in time of next React Native RC:

• config.getProjectConfig() etc. are deprecated for plugin authors and the message says to check the release notes. Once we provide a public interface (in the subsequent PR), update the deprecation message with the right API call and add it to the changelog as well.

Basically

react-native link --platform=ios

My suggestion/improvement for react-native-link command is to add an option to specify where new pod line should be added.

Why will you need it?

Let's say you have a project with multiple targets and multiple pods divided in some section like below:

def react_native_pods() 
  pod 'React', path: '../node_modules/react-native', subspecs: [
    'Core',
    'RCTActionSheet',
    'RCTAnimation',
    'RCTGeolocation',
    'RCTImage',
    'RCTLinkingIOS',
    'RCTNetwork',
    'RCTSettings',
    'RCTText',
    'RCTVibration',
    'RCTWebSocket',
    'CxxBridge',
    'DevSupport',
  ]

  pod 'yoga', path: '../node_modules/react-native/ReactCommon/yoga/yoga.podspec'
  pod 'DoubleConversion', :podspec => '../node_modules/react-native/third-party-podspecs/DoubleConversion.podspec'
  pod 'glog', :podspec => '../node_modules/react-native/third-party-podspecs/glog.podspec'
  pod 'Folly', :podspec => '../node_modules/react-native/third-party-podspecs/Folly.podspec'
end

def customized_pods()
  pod 'react-native-maps', path: '../node_modules/react-native-maps'
end

target 'myFirstTarget' do
 react_native_pods()
end

target 'secondTarget' do
 react_native_pods()
 customized_pods()
end

Now if you are going to link new library eg. react-native-screens it would be awesome to have an option to indicate to which def section new pod line should be added.

Right now, "start" and "bundle" Metro commands are hardcoded in the CLI. We should make a plugin, e.g. "react-native-metro-commands" and move them there.

Would be a good first step towards welcoming other bundlers.

Note: This is non-trivial since both start and bundle have some additional logic, such as "express.js" server that is used by React Native to provide dev tools.

I am pretty sure we need an interface to allow bundlers work with that.

Package entry should be enough + engineStrict.

Instead of requiring private transformer from the "metro/src/...". This is newly created package that has been added to React Native in this commit: facebook/react-native@f5cb4b6

There's a lot on the plate to be done in the upcoming months, I am going to write here a roadmap really soon for you to check and give some suggestions.

Right now, I want to focus on high-priority tasks (bug-fixing, improving "obvious" issues) while keeping work on the v2 in the meantime).

When linking two dependencies that define the same asset, "link" will copy (on Android) or link (on iOS) that asset twice.

We don't check if the asset already exists when linking. At the same time, we also can remove the asset when unlinking.

This is more a note when working on a next version of link.