[local-cli] Add support for custom log reporter cli option for local server

[brentvatne]

Motivation (required)

In Expo tools such as XDE, exp we listen listen to stdout from the packager process and print it in our own buffer. In the case of XDE, an electron app, our log pane is DOM-based, and before printing each log chunk we need to remove special tty characters and sometimes parse it to get information that we need (eg: progress bar). By using a custom reporter, we can take the raw events and pass them along in a format that is easy to consume by XDE and exp. This same motivation applies to create-react-native-app, where we currently don't show a progress bar in the terminal, but we can with this change.

Test Plan (required)

Create LogReporter.js in the root of a project with the CLI changes included in this PR.

class LogReporter {
  update(event) {
    console.log(JSON.stringify(event));
  }
}

module.exports = LogReporter;

Now, run react-native start --customLogReporterPath=LogReporter.js -- all of the raw events will be output as JSON (while the logs that do not go through the reporter, such as the "banner", will remain as-is).

Future considerations that don't prevent this from shipping

• Should we add this option to bundle and unbundle? I don't have a need for this within the context of Expo but it likely makes sense for consistency.
• Speaking of consistency, naming style for CLI arguments is inconsistent between bundle and start -- bundle uses kebab-case and start mostly uses camelCase (exception is resetCache/reset-cache where both are provided, I followed this example for customLogReporterPath/custom-log-reporter-path). Should add the option to use kebab-case for all start options and deprecate the camelCase alternative?
• Are the raw log events likely to change significantly? If so, any changes to these should probably be documented as breaking changes in the release notes in the future.

[hramos]

Thanks for the PR. We may want to add a comment here noting that changes to events could be considered breaking changes, that way anyone touching that file will have to report the breaking change to us and it will be noted in the release notes.

Regarding casing, it looks like both kebab-case and camelCase are accepted for all start flags, even though resetCache is the only one to make a note of it. At least I don't see any special casing for resetCache. If this turns out to be the case for bundle as well, then I would say the best way to address this would be to pick one case to document in the CLI help output for both start and bundle, and silently support the other case as well. I don't see any harm in supporting both.

[facebook-github-bot]

@hramos has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

[facebook-github-bot]

I tried to merge this pull request into the Facebook internal repo but some checks failed. To unblock yourself please check the following: Does this pull request pass all open source tests on GitHub? If not please fix those. Does the code still apply cleanly on top of GitHub master? If not can please rebase. In all other cases this means some internal test failed, for example a part of a fb app won't work with this pull request. I've added the Import Failed label to this pull request so it is easy for someone at fb to find the pull request and check what failed. If you don't see anyone comment in a few days feel free to comment mentioning one of the core contributors to the project so they get a notification.

[brentvatne]

@hramos - any info on what failed?

[hramos]

@brentvatne looks like some trouble rebasing unto our internal codebase. Giving it another try.

[facebook-github-bot]

@hramos has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.