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?