Get rid of a global "react-native-cli" package

[grabbou]

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

[thymikee]

This is a good topic to discuss.

Today we do:

npx react-native-cli init MyProject

(actually RN docs suggests installing a global package, which it's yuck, and we should change it once we're done with this discussion)

And that's nice, because it does everything for us in one command. What's not cool about it however, is that this time user would call react-native-cli, but they can also run yarn react-native from now on. Why having 2 packages doing "the same"? Which is "the" package I'm supposed to use?

Personally I think it would be easy enough to start a project like this:

yarn init # or npm init
yarn add react-native
yarn react-native init MyProject

One package to rule them all. But more verbose. And worse for project maintainers creating new projects all the time (let's say that's not an issue).

The next alternative is to have this baked into react-native itself:

npx react-native init MyProject

Better! But there's quite a bunch of stuff to download for react-native vs react-native-cli (4 vs 52 deps + endless transitive ones). Not sure how relevant is that today since we have package managers that are way more efficient than 2-3 years ago (when react-native-cli was created) and init is a one-time job.

The takeaway is that imho to make the CLI experience delightful for RN users is to make it be a single package (react-native) to rule them all (react-native-local-cli, metro etc). And we're pretty close to that vision. I'm happy to discuss this further and see other views and ideas.

cc @cpojer @rickhanlonii @hramos

[rickhanlonii]

Oh cool!

I like yarn react-native <command>. If we did that right then npx react-native <command> would also work so people could use the workflow they like

Not too concerned with the initial download size difference because if you're starting a react-native project you're going to download react-native. Think of it as warming the cache

[cpojer]

One thing to consider is that npx and yarn use separate caches, so if you were using both, the cache has to be warmed up twice.

[pvinis]

do you mean npx or npm?

[cpojer]

They use the same cache for global modules.

[pvinis]

I thought npx was for executing stuff, but I guess it can also install stuff, in which case it would use the npm cache. cool :)

I guess if people use npm and npx, that's fine. if they use yarn and yarn foo, that's also fine. if they combine, then sure, 2 caches, but that's something people should know in general, not just for this issue.

so the warming up is a valid reason here I think.

[thymikee]

@cpojer is there a proposal for npx equivalent for yarn? there was yarn create but I don't think it covers this use case?

[cpojer]

I don't think there is but since the logic is already there with create, it should be easy to propose a new command and send a PR with the same feature.

[thymikee]

Time to prepare a RFC for this then. I'll try to set this up this week, but if anybody willing to work on it earlier, feel free to do so and make us know :)

[thymikee]

FYI I've spoken to @arcanis and I plan to PR a new yarn gx command (global execute) that would install the package globally populating the cache (would most likely base on yarn create code).

So, if you're npm fan you'll use

npx react-native init MyApp

And for Yarn lovers:

yarn gx react-native init MyApp

How does that sound?

[cpojer]

I think that's good. We could make it so that react-native-cli gets updated and just calls either of the two.

[thymikee]

You mean for the back compat? I thought about ditching that package and don't mention it in official docs

[cpojer]

Yeah, for backwards compat we should probably do it.

[pvinis]

isn't yarn bla looking for a script called bla first, and then looking for a local bin called bla?

[rickhanlonii]

@thymikee I'm not in love with it - it seems to do the same as yarn create but doesn't have most of the advantages of npx. If you put in an RFC, I can leave some thoughts

[thymikee]

I'll let you all know once I make RFC, I didn't post everything in my comment :D

[thymikee]

FYI yarnpkg/rfcs#113

[thymikee]

We're not getting rid of it, however some day we'll remove the legacy init living there and make it to be only a proxy to the actual CLI for convenience if some prefer global packages.