Contributing to the CLI

Where stuff lives

Parts of the CLI:

1. Code to identify the correct version of react-native-windows to install, and install it:
   [Root]\packages\react-native-windows-init
2. Template code: The code that actually creates the files needed to to run a create and run react-native-windows app here:
   [Root]\packages\@react-native-windows\cli
3. Code for run-windows and other commands run through react-native <foo> Also in [Root]\packages\@react-native-windows\cli

How to test local changes to the project init CLI:

1. If you are making changes to the react-native-windows-init code, you can build the code locally using yarn build, then manually call into the CLI by using node <root>\packages\react-native-windows-init\lib-commonjs\Cli.js -- You can pass parameters to that as usual, or use node --inspect-brk ... to allow you to attach to the call using VSCode.
2. If you are making changes to the vnext part of the CLI, you can install RNW from your local enlistment by supplying the --version parameter to the react-native-windows-init command. For example:
   npx react-native-windows-init --version file:d:\rnw\vnext

Testing changes in @react-native-windows\cli

Since the cli script will load all scripts under local-cli folder from the version that you are deploying any changes there (like the templates) will not be picked up since they will be used from the version of the react-native-windows package installed. You can pass the path to the package as the version to test this.

1. node <root>\node_modules\react-native-windows-init\bin.js --language cpp --version file:<root>\vnext See #4946

Note: that yarn does a copy of all the files under vnext to install react-native-windows. Unlike when the package has been published, this will include all the native built files which would normally be excluded by npmignore. You should delete the build, target and packages folder from vnext. Otherwise the command will have to copy GBs of data to install react-native-windows from your local path

A Faster way to test the react-native-windows-init CLI:

While the above may be the safest way, it is also the slowest as per the note. It will copy all files in your vnext folder over to your node_modules folder of the test project. If you have a bunch of flavors build this can add up. I had about 29gigs of outputs. This made it extremely slow to copy each time. It will also create a unique copy in the yarn cache folder potentially causing your disk to run out of space, as running this 20 times requires ~600gigs. There is now an alternative way to 'link' in the package from your enlistment folder. This has the added benefit that changes to other files in the package like in the PropertySheets folder are immediately visible and don't require rerunning the project init to pick up.

1. Navigate to the <root>/vnext folder in your repo
2. Run yarn link

   If you get an error that another folder has already registered it simply run yarn unlink and then try again.

3. node <root>\packages\react-native-windows-init\lib-commonjs\Cli.js --version 0.0.0 --useDevMode and any other options

   The version doesn't matter in this case as the version in <root>/venxt/package.json will be used. and --useDevMode indicates to link the package from the previous step

How to debug other CLI commands:

The easiest way to to debug is using VS Code. You just need to create a configuration within your template app directory that tells VS Code to launch the CLI in an instance of node and debug node on startup. Here's an example launch.json with a single configuration:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "react-native windows",
      "program": "${workspaceRoot}/node_modules/react-native/cli.js",
      "args": ["run-windows"],
      "stopOnEntry": true
    }
  ],
  "compounds": []
}