Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extract CLI from core #13

Merged
merged 3 commits into from
Sep 24, 2018
+62 −0
Merged

Extract CLI from core #13

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
df5a4eb
Create 0002-Extracted-Command-Line-Tools.md
grabbou Aug 10, 2018
14b0739
Update proposal to make it more specific
grabbou Aug 20, 2018
6408c3e
Update 0002-Extracted-Command-Line-Tools.md
grabbou Sep 19, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
62 changes: 62 additions & 0 deletions proposals/0002-Extracted-Command-Line-Tools.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,62 @@
---
title: Extract CLI from Core
author:
- Mike Grabowski
date: 2018-08-10
---

# RFC0003: Extract CLI from Core

## Summary

Extract the current CLI implementation from React Native Core and move it into a third party package.

## Basic example
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we just call this section "Background", even in the template ? Looks like almost all proposals seem to need a background section, talking about the state of the world.


Command line tools in React Native are split into two, separate pieces.

First one is the `react-native-cli` package that we prompt users to install globally, for the first time they actually interact with the framework. This package, by the design, is not meant to be frequently updated, which eliminates many annoying issues that global packages are infamous for.

The second one is `local-cli` package which is the actual source code of the CLI. It is a set of multiple commands, each of them grouped into a standalone module, that are loaded altogether when the CLI is spawned.

The biggest part of the `local-cli` is its `core`, which is capable of analyzing your source code. It provides a context object for all the commands, that contains necessary information about the location of your source files, available platforms and more. Commands such as `link`, `unlink` or `run-ios` use that information to perform their work.

This proposal suggests no changes to the end user in its first iteration. We would simply couple new package with React Native version, just like we do with Metro. That makes it possible to still make React Native version specific changes to the CLI itself.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like we’ve often run into problems with metro versions being so tightly coupled to RN releases. Will that not be a problem here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really - we will still bundle the CLI with React Native to start with (just like we bundle Metro as a dependency). In reality, there are less and less features that need to be updated for new React Native releases. In most cases, it's due to Metro changing the interface, which we can track here as well.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to define what the features of "first iteration" really are, before declaring that there would be no changes. Maybe more this sentence to later ?


## Motivation

Facebook does not use the CLI provided with React Native, which makes it hard to maintain the project. There is no clear owner and issues / pull requests get stuck in the sea of other, non-CLI related reports.

It is also hard to keep moving on the CLI as every additional dependency or code change is subject to the heavy review process and sync.

Extracting it out would be the first step to make React Native CLI agnostic, allowing other tools (including Webpack via Haul) to become first-class citizens and use common design infrastructure.

## Detailed design

The goal of this proposal is to extract the CLI out of the React Native repository into a separate project, called `react-native-cli`, that would become a direct dependency of React Native. It is similar to the extraction process of `Metro`.

That includes moving out two folders:
- `local-cli`, where business logic of the CLI and all available commands are located
- `react-native-cli`, where global package for running `react-native init` lives

Development of these two packages would take place under one repository.

Since `metro` isn't required anywhere else outside of `local-cli` folder (where the business logic of the CLI is located), it would be removed from the React Native dependencies and become the depdendency of newly created `react-native-cli`.

## Drawbacks

Every time the new release of React Native is cut, few dependencies must be updated (`metro` in particular). Due to the way Facebook develops their products internally using monorepo, the version of `metro` must be set manually by the Metro team right after they release their version to the `npm` registry.

After extracting out `react-native-cli` to a separate repository and `metro` becoming its dependency, Metro team would have to update the version inside that project instead. React Native CLI maintainers would then make sure to update the versions when cutting new release.

## Alternatives

There's Haul - an open source project by Callstack - in development that uses Webpack instead of Metro to bundle React Native code. It is a different project having different goals. Unfortunately, due to tight-coupling of `local-cli` with React Native, it became hard to integrate these two together.

## Adoption strategy

The CLI would roll out as an independent package automatically with one of the upcoming React Native versions.

## How we teach this

Clear communication in the changelog. Printed instructions on how to fill in bug report right after the CLI ends up with non-zero exit code.