[FEAT] Separate Tabs for npm run and yarn commands

[Pranav-yadav]

Summary

We're steering away from npx due to its unreliability and switching to npm run and yarn instead, for package.json scripts.

e.g.:

npm Tab	yarn Tab

RN Main PR: react/react-native#37521

Context

This was discussed here: react/react-native#37521 (comment)

---

P.S.: What this PR does not changes is; other npx react-native commands such as init, upgrade, bundle, etc. Since, those commands will need proper testing before such change.

[netlify]

✅ Deploy Preview for react-native ready!

Name	Link
🔨 Latest commit	f93553f
🔍 Latest deploy log	https://app.netlify.com/sites/react-native/deploys/64887cd42811b30007cfda8a
😎 Deploy Preview	https://deploy-preview-3732--react-native.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[Pranav-yadav]

@kelset, I assume, this won't need to be backported to prev 1 or 2 (or even all) majors (versioned docs)?
lmk

[kelset]

@kelset, I assume, this won't need to be backported to prev 1 or 2 (or even all) majors (versioned docs)? lmk

no I think it's ok to just have it for 0.72, so it's consistent with your other PR.

cc @Simek this one LGTM, we can merge before the 0.72 docs cut 👍

[Pranav-yadav]

Sure.
Just so that we don't miss this (apart from this PR):

P.S.: What this PR does not changes is; other npx react-native commnds such as init, upgrade, bundle, etc. Since, those commands will need proper testing before such change.

@cortinico I can open a PR for those changes (switching to yarn react-native) as well; but, I don't have proper set up to test changes such and bundle and related testing.

[Simek]

Are there any known issues related to command switch or any migration tips that we could include?

[Pranav-yadav]

Are there any known issues related to command switch or any migration tips that we could include?

As I mentioned in the PR description; specifically the table, we're only changing commands (the way we call npm scripts, also not the scripts) that everyone has been using for so long time but, no one changed it on the website 🙂,
and not changing commands that will require some testing as I've mentined in the previous comment.

[kelset]

Are there any known issues related to command switch or any migration tips that we could include?

nothing changes, we are just pointing people to the better and safer approach. Everything stays the same for the end user.

[NickGerleman]

The documentation shows separate examples for Yarn and NPM, and has tabs for when instructions are different between them.

See as an example, the usage of constants.packageManagers in getting-started.md.

This change moves instructions which currently work for any package manager, and makes them only work on yarn, outside of a yarn-specific tab.

[NickGerleman]

We're steering away from npx due to it's unreliability

I would be interested to know more about this. Is this maybe looking at npx behavior around executing remote packages?

[kelset]

Is this maybe looking at npx behavior around executing remote packages?

Not just that, also about the fact that npx means that the behaviour you get changes over time potentially, and there's the extra complication of what version of the command npx picks up based on caching and stuff... it's a minefield, so if we can avoid setting up users for useless pain it'd be much better for everyone.

[Pranav-yadav]

We're steering away from npx due to it's unreliability

I would be interested to know more about this. Is this maybe looking at npx behavior around executing remote packages?

@kelset and @cortinico can better explain this.

P.S.: Everyone can follow the "context"; link provided in PR description, for the prior relevant discussion which requested this PR.
Here: [1] react/react-native#37521 (comment)
[2] react/react-native#37521 (comment)

[NickGerleman]

Is this maybe looking at npx behavior around executing remote packages?

Not just that, also about the fact that npx means that the behaviour you get changes over time potentially, and there's the extra complication of what version of the command npx picks up based on caching and stuff... it's a minefield, so if we can avoid setting up users for useless pain it'd be much better for everyone.

This is not applicable to using npx to run local scripts.

[kelset]

Care to expand and put links to back what you are trying to say? I am not sure I understand. My point is that npx is complicated and unreliable, and I'd rather not set people approaching react-native for the first time to having to deal with something like that.

[Pranav-yadav]

I'll be taking a break, since finished with exams and haven't taken one in a while 😅.
I've "Allowed edits by maintainers". So, please "feel free to suggest and commit changes" as you feel right.
Thanks for reviewing and providing feedback

[NickGerleman]

Care to expand and put links to back what you are trying to say? I am not sure I understand. My point is that npx is complicated and unreliable, and I'd rather not set people approaching react-native for the first time to having to deal with something like that.

I think "Let's not recommend npx because it's unreliable" is misguided and not really accurate. The issue that I'm guessing this roots from was around running npx react-native init and it possibly not fetching the latest version?

Apart from imo being more a CLI bug, this scenario is specific to using npx to dowload and execute remote packages, a functionality that is fully distinct from using it for executing something already installed. Node 16+ has made that separation in the command clearer too, requiring acknowledgement any time something remote is executed. npx is still the de-facto way to portably execute an installed bin entry.

I'm also not sure switching out a confined part to yarn helps at all with the goal of "discourage npx", since right before this we tell people to use npx to init their app, in the "problematic" case of npx remote fetch. And in this case there isn't an alternative.

[NickGerleman]

With all that said, if we want to encourage running the package.json steps instead, I think recommending “yarn” and “npm run” is fine.

Intersecting with the README, IIRC it is a documented flow to initialize a project using npm, so we’d want to double check those users get the right commands in their new project README.

[kelset]

@NickGerleman let me try to recap what I think we might have reached as an agreement for what we want to document to the users (both here and in the other PR react/react-native#37521):

• npx is kept for the init command in the form of npx react-native@latest init ...
• for all the other commands that are locally available in the package.json of the template like android, ios, start, etc, we will change the docs to yarn/npm run

This sounds good to me, let us know so that we have ✅ and we can let @Pranav-yadav complete this work (sorry it's taking so long Pranav 🙇‍♂️)

[NickGerleman]

We can do that. See the examples in #3732 (review) for how to provide different tabs for npm vs yarn on the website.

Then see https://github.com/react-native-community/cli/blob/cd981848a50565cf416fbf60d0b66720f6ddd511/packages/cli/src/commands/init/init.ts#L29 for the entrypoint to CLI code for building a new project which uses npm instead of yarn. In that case, the README in the newly generated project would need to tell users to use npm run instead of the yarn commands.

[Pranav-yadav]

Sure. Will take a look at it day-after-tomorrow.

^{P.S.: Busy with an interview tomorrow :)}

[Pranav-yadav]

@NickGerleman@kelset added separate tabs for npm run and yarn commands.
^{Edit 2: Removed this completely. --> P.S.: Left a few inline comments for you. <-- Edit: Please ignore those comments as those changes are out-of-scope for this PR, will do a follow-up PR if required :) as those changes will need more discussion.}

Also, added markdown touchups wherever necessary, such as adding ``` blocks for codes that were formatted using TABs and language formatting such as ```xml

[Pranav-yadav]

Following are the live deployed preview — direct links for the changes made in this PR 😇
Make sure you check all the OS, Languages, and Package Manager Tabs 👍:

1. https://deploy-preview-3732--react-native.netlify.app/docs/next/environment-setup?guide=native#development-os
2. https://deploy-preview-3732--react-native.netlify.app/docs/next/integration-with-existing-apps
3. https://deploy-preview-3732--react-native.netlify.app/docs/next/running-on-device
4. https://deploy-preview-3732--react-native.netlify.app/docs/next/running-on-simulator-ios
5. https://deploy-preview-3732--react-native.netlify.app/docs/next/hermes#android
6. https://deploy-preview-3732--react-native.netlify.app/docs/next/libraries#installing-a-library
7. https://deploy-preview-3732--react-native.netlify.app/docs/next/native-modules-android#:~:text=The%20final%20step%20is%20to%20rebuild%20the%20React%20Native%20app%20so%20that%20you%20can%20have%20the%20latest%20native%20code%20(with%20your%20new%20native%20module!)%20available.%20In%20your%20command%20line%2C%20where%20the%20react%20native%20application%20is%20located%2C%20run%20the%20following%3A
8. https://deploy-preview-3732--react-native.netlify.app/docs/next/native-modules-ios#:~:text=The%20final%20step%20is%20to%20rebuild%20the%20React%20Native%20app%20so%20that%20you%20can%20have%20the%20latest%20native%20code%20(with%20your%20new%20native%20module!)%20available.%20In%20your%20command%20line%2C%20where%20the%20react%20native%20application%20is%20located%2C%20run%20the%20following%20%3A
9. https://deploy-preview-3732--react-native.netlify.app/docs/next/publishing-to-app-store#:~:text=(e.g.%20from%20the%20root%20of%20your%20project%3A%20npm%20run%20ios%20%2D%2D%20%2D%2Dmode%3D%22release%22%20or%20yarn%20ios%20%2D%2Dmode%20release).
10. https://deploy-preview-3732--react-native.netlify.app/docs/next/signed-apk-android#testing-the-release-build-of-your-app
11. https://deploy-preview-3732--react-native.netlify.app/docs/next/troubleshooting#using-a-port-other-than-8081

[NickGerleman]

Everything else here LGTM

[Pranav-yadav]

@kelset, I assume, this won't need to be backported to prev 1 or 2 (or even all) majors (versioned docs)? lmk

no I think it's ok to just have it for 0.72, so it's consistent with your other PR.

cc @Simek this one LGTM, we can merge before the 0.72 docs cut 👍

-- #3732 (comment)

Reminder; so we don't forget to merge this before the 0.72 cut 👍

Also, since this PR ended up being a generic sitewide change, this should not be blocked by the other RN PR :)

[kelset]

@Simek now that Nick gave his ✅ we can go ahead and merge this

[Simek]

LGTM, thank you for all the updates and work put into improving those command in the first place! 👍

[kelset]

🎉🎉🎉

[Pranav-yadav]

Thank you very much @kelset, @NickGerleman & @Simek ❤️ for your feedback and reviews.
PRs like this one have been teaching me a lot about having patience and thinking about the overall system and not just focusing on the ultimate goal.

[Pranav-yadav]

Summary

We're steering away from npx due to its unreliability and switching to npm run and yarn instead, for package.json scripts.

e.g.:

npm Tab	yarn Tab

RN Main PR: react/react-native#37521

Context

This was discussed here: react/react-native#37521 (comment)

---

P.S.: What this PR does not changes is; other npx react-native commands such as init, upgrade, bundle, etc. Since, those commands will need proper testing before such change.

[netlify]

✅ Deploy Preview for react-native ready!

Name	Link
🔨 Latest commit	f93553f
🔍 Latest deploy log	https://app.netlify.com/sites/react-native/deploys/64887cd42811b30007cfda8a
😎 Deploy Preview	https://deploy-preview-3732--react-native.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[Pranav-yadav]

@kelset, I assume, this won't need to be backported to prev 1 or 2 (or even all) majors (versioned docs)?
lmk

[kelset]

@kelset, I assume, this won't need to be backported to prev 1 or 2 (or even all) majors (versioned docs)? lmk

no I think it's ok to just have it for 0.72, so it's consistent with your other PR.

cc @Simek this one LGTM, we can merge before the 0.72 docs cut 👍

[Pranav-yadav]

Sure.
Just so that we don't miss this (apart from this PR):

P.S.: What this PR does not changes is; other npx react-native commnds such as init, upgrade, bundle, etc. Since, those commands will need proper testing before such change.

@cortinico I can open a PR for those changes (switching to yarn react-native) as well; but, I don't have proper set up to test changes such and bundle and related testing.

[Simek]

Are there any known issues related to command switch or any migration tips that we could include?

[Pranav-yadav]

Are there any known issues related to command switch or any migration tips that we could include?

As I mentioned in the PR description; specifically the table, we're only changing commands (the way we call npm scripts, also not the scripts) that everyone has been using for so long time but, no one changed it on the website 🙂,
and not changing commands that will require some testing as I've mentined in the previous comment.

[kelset]

Are there any known issues related to command switch or any migration tips that we could include?

nothing changes, we are just pointing people to the better and safer approach. Everything stays the same for the end user.

[NickGerleman]

The documentation shows separate examples for Yarn and NPM, and has tabs for when instructions are different between them.

See as an example, the usage of constants.packageManagers in getting-started.md.

This change moves instructions which currently work for any package manager, and makes them only work on yarn, outside of a yarn-specific tab.

[NickGerleman]

We're steering away from npx due to it's unreliability

I would be interested to know more about this. Is this maybe looking at npx behavior around executing remote packages?

[kelset]

Is this maybe looking at npx behavior around executing remote packages?

Not just that, also about the fact that npx means that the behaviour you get changes over time potentially, and there's the extra complication of what version of the command npx picks up based on caching and stuff... it's a minefield, so if we can avoid setting up users for useless pain it'd be much better for everyone.

[Pranav-yadav]

We're steering away from npx due to it's unreliability

I would be interested to know more about this. Is this maybe looking at npx behavior around executing remote packages?

@kelset and @cortinico can better explain this.

P.S.: Everyone can follow the "context"; link provided in PR description, for the prior relevant discussion which requested this PR.
Here: [1] react/react-native#37521 (comment)
[2] react/react-native#37521 (comment)

[NickGerleman]

Is this maybe looking at npx behavior around executing remote packages?

Not just that, also about the fact that npx means that the behaviour you get changes over time potentially, and there's the extra complication of what version of the command npx picks up based on caching and stuff... it's a minefield, so if we can avoid setting up users for useless pain it'd be much better for everyone.

This is not applicable to using npx to run local scripts.

[kelset]

Care to expand and put links to back what you are trying to say? I am not sure I understand. My point is that npx is complicated and unreliable, and I'd rather not set people approaching react-native for the first time to having to deal with something like that.

[Pranav-yadav]

I'll be taking a break, since finished with exams and haven't taken one in a while 😅.
I've "Allowed edits by maintainers". So, please "feel free to suggest and commit changes" as you feel right.
Thanks for reviewing and providing feedback

[NickGerleman]

Care to expand and put links to back what you are trying to say? I am not sure I understand. My point is that npx is complicated and unreliable, and I'd rather not set people approaching react-native for the first time to having to deal with something like that.

I think "Let's not recommend npx because it's unreliable" is misguided and not really accurate. The issue that I'm guessing this roots from was around running npx react-native init and it possibly not fetching the latest version?

Apart from imo being more a CLI bug, this scenario is specific to using npx to dowload and execute remote packages, a functionality that is fully distinct from using it for executing something already installed. Node 16+ has made that separation in the command clearer too, requiring acknowledgement any time something remote is executed. npx is still the de-facto way to portably execute an installed bin entry.

I'm also not sure switching out a confined part to yarn helps at all with the goal of "discourage npx", since right before this we tell people to use npx to init their app, in the "problematic" case of npx remote fetch. And in this case there isn't an alternative.

[NickGerleman]

With all that said, if we want to encourage running the package.json steps instead, I think recommending “yarn” and “npm run” is fine.

Intersecting with the README, IIRC it is a documented flow to initialize a project using npm, so we’d want to double check those users get the right commands in their new project README.

[kelset]

@NickGerleman let me try to recap what I think we might have reached as an agreement for what we want to document to the users (both here and in the other PR react/react-native#37521):

• npx is kept for the init command in the form of npx react-native@latest init ...
• for all the other commands that are locally available in the package.json of the template like android, ios, start, etc, we will change the docs to yarn/npm run

This sounds good to me, let us know so that we have ✅ and we can let @Pranav-yadav complete this work (sorry it's taking so long Pranav 🙇‍♂️)

[NickGerleman]

We can do that. See the examples in #3732 (review) for how to provide different tabs for npm vs yarn on the website.

Then see https://github.com/react-native-community/cli/blob/cd981848a50565cf416fbf60d0b66720f6ddd511/packages/cli/src/commands/init/init.ts#L29 for the entrypoint to CLI code for building a new project which uses npm instead of yarn. In that case, the README in the newly generated project would need to tell users to use npm run instead of the yarn commands.

[Pranav-yadav]

Sure. Will take a look at it day-after-tomorrow.

^{P.S.: Busy with an interview tomorrow :)}

[Pranav-yadav]

@NickGerleman@kelset added separate tabs for npm run and yarn commands.
^{Edit 2: Removed this completely. --> P.S.: Left a few inline comments for you. <-- Edit: Please ignore those comments as those changes are out-of-scope for this PR, will do a follow-up PR if required :) as those changes will need more discussion.}

Also, added markdown touchups wherever necessary, such as adding ``` blocks for codes that were formatted using TABs and language formatting such as ```xml

[Pranav-yadav]

Following are the live deployed preview — direct links for the changes made in this PR 😇
Make sure you check all the OS, Languages, and Package Manager Tabs 👍:

1. https://deploy-preview-3732--react-native.netlify.app/docs/next/environment-setup?guide=native#development-os
2. https://deploy-preview-3732--react-native.netlify.app/docs/next/integration-with-existing-apps
3. https://deploy-preview-3732--react-native.netlify.app/docs/next/running-on-device
4. https://deploy-preview-3732--react-native.netlify.app/docs/next/running-on-simulator-ios
5. https://deploy-preview-3732--react-native.netlify.app/docs/next/hermes#android
6. https://deploy-preview-3732--react-native.netlify.app/docs/next/libraries#installing-a-library
7. https://deploy-preview-3732--react-native.netlify.app/docs/next/native-modules-android#:~:text=The%20final%20step%20is%20to%20rebuild%20the%20React%20Native%20app%20so%20that%20you%20can%20have%20the%20latest%20native%20code%20(with%20your%20new%20native%20module!)%20available.%20In%20your%20command%20line%2C%20where%20the%20react%20native%20application%20is%20located%2C%20run%20the%20following%3A
8. https://deploy-preview-3732--react-native.netlify.app/docs/next/native-modules-ios#:~:text=The%20final%20step%20is%20to%20rebuild%20the%20React%20Native%20app%20so%20that%20you%20can%20have%20the%20latest%20native%20code%20(with%20your%20new%20native%20module!)%20available.%20In%20your%20command%20line%2C%20where%20the%20react%20native%20application%20is%20located%2C%20run%20the%20following%20%3A
9. https://deploy-preview-3732--react-native.netlify.app/docs/next/publishing-to-app-store#:~:text=(e.g.%20from%20the%20root%20of%20your%20project%3A%20npm%20run%20ios%20%2D%2D%20%2D%2Dmode%3D%22release%22%20or%20yarn%20ios%20%2D%2Dmode%20release).
10. https://deploy-preview-3732--react-native.netlify.app/docs/next/signed-apk-android#testing-the-release-build-of-your-app
11. https://deploy-preview-3732--react-native.netlify.app/docs/next/troubleshooting#using-a-port-other-than-8081

[NickGerleman]

Everything else here LGTM

[Pranav-yadav]

@kelset, I assume, this won't need to be backported to prev 1 or 2 (or even all) majors (versioned docs)? lmk

no I think it's ok to just have it for 0.72, so it's consistent with your other PR.

cc @Simek this one LGTM, we can merge before the 0.72 docs cut 👍

-- #3732 (comment)

Reminder; so we don't forget to merge this before the 0.72 cut 👍

Also, since this PR ended up being a generic sitewide change, this should not be blocked by the other RN PR :)

[kelset]

@Simek now that Nick gave his ✅ we can go ahead and merge this

[Simek]

LGTM, thank you for all the updates and work put into improving those command in the first place! 👍

[kelset]

🎉🎉🎉

[Pranav-yadav]

Thank you very much @kelset, @NickGerleman & @Simek ❤️ for your feedback and reviews.
PRs like this one have been teaching me a lot about having patience and thinking about the overall system and not just focusing on the ultimate goal.

[Pranav-yadav]

Summary

We're steering away from npx due to its unreliability and switching to npm run and yarn instead, for package.json scripts.

e.g.:

npm Tab	yarn Tab

RN Main PR: react/react-native#37521

Context

This was discussed here: react/react-native#37521 (comment)

---

P.S.: What this PR does not changes is; other npx react-native commands such as init, upgrade, bundle, etc. Since, those commands will need proper testing before such change.

[netlify]

✅ Deploy Preview for react-native ready!

Name	Link
🔨 Latest commit	f93553f
🔍 Latest deploy log	https://app.netlify.com/sites/react-native/deploys/64887cd42811b30007cfda8a
😎 Deploy Preview	https://deploy-preview-3732--react-native.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[Pranav-yadav]

@kelset, I assume, this won't need to be backported to prev 1 or 2 (or even all) majors (versioned docs)?
lmk

[kelset]

@kelset, I assume, this won't need to be backported to prev 1 or 2 (or even all) majors (versioned docs)? lmk

no I think it's ok to just have it for 0.72, so it's consistent with your other PR.

cc @Simek this one LGTM, we can merge before the 0.72 docs cut 👍

[Pranav-yadav]

Sure.
Just so that we don't miss this (apart from this PR):

P.S.: What this PR does not changes is; other npx react-native commnds such as init, upgrade, bundle, etc. Since, those commands will need proper testing before such change.

@cortinico I can open a PR for those changes (switching to yarn react-native) as well; but, I don't have proper set up to test changes such and bundle and related testing.

[Simek]

Are there any known issues related to command switch or any migration tips that we could include?

[Pranav-yadav]

Are there any known issues related to command switch or any migration tips that we could include?

As I mentioned in the PR description; specifically the table, we're only changing commands (the way we call npm scripts, also not the scripts) that everyone has been using for so long time but, no one changed it on the website 🙂,
and not changing commands that will require some testing as I've mentined in the previous comment.

[kelset]

Are there any known issues related to command switch or any migration tips that we could include?

nothing changes, we are just pointing people to the better and safer approach. Everything stays the same for the end user.

[NickGerleman]

The documentation shows separate examples for Yarn and NPM, and has tabs for when instructions are different between them.

See as an example, the usage of constants.packageManagers in getting-started.md.

This change moves instructions which currently work for any package manager, and makes them only work on yarn, outside of a yarn-specific tab.

[NickGerleman]

We're steering away from npx due to it's unreliability

I would be interested to know more about this. Is this maybe looking at npx behavior around executing remote packages?

[kelset]

Is this maybe looking at npx behavior around executing remote packages?

Not just that, also about the fact that npx means that the behaviour you get changes over time potentially, and there's the extra complication of what version of the command npx picks up based on caching and stuff... it's a minefield, so if we can avoid setting up users for useless pain it'd be much better for everyone.

[Pranav-yadav]

We're steering away from npx due to it's unreliability

I would be interested to know more about this. Is this maybe looking at npx behavior around executing remote packages?

@kelset and @cortinico can better explain this.

P.S.: Everyone can follow the "context"; link provided in PR description, for the prior relevant discussion which requested this PR.
Here: [1] react/react-native#37521 (comment)
[2] react/react-native#37521 (comment)

[NickGerleman]

Is this maybe looking at npx behavior around executing remote packages?

Not just that, also about the fact that npx means that the behaviour you get changes over time potentially, and there's the extra complication of what version of the command npx picks up based on caching and stuff... it's a minefield, so if we can avoid setting up users for useless pain it'd be much better for everyone.

This is not applicable to using npx to run local scripts.

[kelset]

Care to expand and put links to back what you are trying to say? I am not sure I understand. My point is that npx is complicated and unreliable, and I'd rather not set people approaching react-native for the first time to having to deal with something like that.

[Pranav-yadav]

I'll be taking a break, since finished with exams and haven't taken one in a while 😅.
I've "Allowed edits by maintainers". So, please "feel free to suggest and commit changes" as you feel right.
Thanks for reviewing and providing feedback

[NickGerleman]

Care to expand and put links to back what you are trying to say? I am not sure I understand. My point is that npx is complicated and unreliable, and I'd rather not set people approaching react-native for the first time to having to deal with something like that.

I think "Let's not recommend npx because it's unreliable" is misguided and not really accurate. The issue that I'm guessing this roots from was around running npx react-native init and it possibly not fetching the latest version?

Apart from imo being more a CLI bug, this scenario is specific to using npx to dowload and execute remote packages, a functionality that is fully distinct from using it for executing something already installed. Node 16+ has made that separation in the command clearer too, requiring acknowledgement any time something remote is executed. npx is still the de-facto way to portably execute an installed bin entry.

I'm also not sure switching out a confined part to yarn helps at all with the goal of "discourage npx", since right before this we tell people to use npx to init their app, in the "problematic" case of npx remote fetch. And in this case there isn't an alternative.

[NickGerleman]

With all that said, if we want to encourage running the package.json steps instead, I think recommending “yarn” and “npm run” is fine.

Intersecting with the README, IIRC it is a documented flow to initialize a project using npm, so we’d want to double check those users get the right commands in their new project README.

[kelset]

@NickGerleman let me try to recap what I think we might have reached as an agreement for what we want to document to the users (both here and in the other PR react/react-native#37521):

• npx is kept for the init command in the form of npx react-native@latest init ...
• for all the other commands that are locally available in the package.json of the template like android, ios, start, etc, we will change the docs to yarn/npm run

This sounds good to me, let us know so that we have ✅ and we can let @Pranav-yadav complete this work (sorry it's taking so long Pranav 🙇‍♂️)

[NickGerleman]

We can do that. See the examples in #3732 (review) for how to provide different tabs for npm vs yarn on the website.

Then see https://github.com/react-native-community/cli/blob/cd981848a50565cf416fbf60d0b66720f6ddd511/packages/cli/src/commands/init/init.ts#L29 for the entrypoint to CLI code for building a new project which uses npm instead of yarn. In that case, the README in the newly generated project would need to tell users to use npm run instead of the yarn commands.

[Pranav-yadav]

Sure. Will take a look at it day-after-tomorrow.

^{P.S.: Busy with an interview tomorrow :)}

[Pranav-yadav]

@NickGerleman@kelset added separate tabs for npm run and yarn commands.
^{Edit 2: Removed this completely. --> P.S.: Left a few inline comments for you. <-- Edit: Please ignore those comments as those changes are out-of-scope for this PR, will do a follow-up PR if required :) as those changes will need more discussion.}

Also, added markdown touchups wherever necessary, such as adding ``` blocks for codes that were formatted using TABs and language formatting such as ```xml

[Pranav-yadav]

Following are the live deployed preview — direct links for the changes made in this PR 😇
Make sure you check all the OS, Languages, and Package Manager Tabs 👍:

1. https://deploy-preview-3732--react-native.netlify.app/docs/next/environment-setup?guide=native#development-os
2. https://deploy-preview-3732--react-native.netlify.app/docs/next/integration-with-existing-apps
3. https://deploy-preview-3732--react-native.netlify.app/docs/next/running-on-device
4. https://deploy-preview-3732--react-native.netlify.app/docs/next/running-on-simulator-ios
5. https://deploy-preview-3732--react-native.netlify.app/docs/next/hermes#android
6. https://deploy-preview-3732--react-native.netlify.app/docs/next/libraries#installing-a-library
7. https://deploy-preview-3732--react-native.netlify.app/docs/next/native-modules-android#:~:text=The%20final%20step%20is%20to%20rebuild%20the%20React%20Native%20app%20so%20that%20you%20can%20have%20the%20latest%20native%20code%20(with%20your%20new%20native%20module!)%20available.%20In%20your%20command%20line%2C%20where%20the%20react%20native%20application%20is%20located%2C%20run%20the%20following%3A
8. https://deploy-preview-3732--react-native.netlify.app/docs/next/native-modules-ios#:~:text=The%20final%20step%20is%20to%20rebuild%20the%20React%20Native%20app%20so%20that%20you%20can%20have%20the%20latest%20native%20code%20(with%20your%20new%20native%20module!)%20available.%20In%20your%20command%20line%2C%20where%20the%20react%20native%20application%20is%20located%2C%20run%20the%20following%20%3A
9. https://deploy-preview-3732--react-native.netlify.app/docs/next/publishing-to-app-store#:~:text=(e.g.%20from%20the%20root%20of%20your%20project%3A%20npm%20run%20ios%20%2D%2D%20%2D%2Dmode%3D%22release%22%20or%20yarn%20ios%20%2D%2Dmode%20release).
10. https://deploy-preview-3732--react-native.netlify.app/docs/next/signed-apk-android#testing-the-release-build-of-your-app
11. https://deploy-preview-3732--react-native.netlify.app/docs/next/troubleshooting#using-a-port-other-than-8081

[NickGerleman]

Everything else here LGTM

[Pranav-yadav]

@kelset, I assume, this won't need to be backported to prev 1 or 2 (or even all) majors (versioned docs)? lmk

no I think it's ok to just have it for 0.72, so it's consistent with your other PR.

cc @Simek this one LGTM, we can merge before the 0.72 docs cut 👍

-- #3732 (comment)

Reminder; so we don't forget to merge this before the 0.72 cut 👍

Also, since this PR ended up being a generic sitewide change, this should not be blocked by the other RN PR :)

[kelset]

@Simek now that Nick gave his ✅ we can go ahead and merge this

[Simek]

LGTM, thank you for all the updates and work put into improving those command in the first place! 👍

[kelset]

🎉🎉🎉

[Pranav-yadav]

Thank you very much @kelset, @NickGerleman & @Simek ❤️ for your feedback and reviews.
PRs like this one have been teaching me a lot about having patience and thinking about the overall system and not just focusing on the ultimate goal.

[Pranav-yadav]

Summary

We're steering away from npx due to its unreliability and switching to npm run and yarn instead, for package.json scripts.

e.g.:

npm Tab	yarn Tab

RN Main PR: react/react-native#37521

Context

This was discussed here: react/react-native#37521 (comment)

---

P.S.: What this PR does not changes is; other npx react-native commands such as init, upgrade, bundle, etc. Since, those commands will need proper testing before such change.

[netlify]

✅ Deploy Preview for react-native ready!

Name	Link
🔨 Latest commit	f93553f
🔍 Latest deploy log	https://app.netlify.com/sites/react-native/deploys/64887cd42811b30007cfda8a
😎 Deploy Preview	https://deploy-preview-3732--react-native.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[Pranav-yadav]

@kelset, I assume, this won't need to be backported to prev 1 or 2 (or even all) majors (versioned docs)?
lmk

[kelset]

@kelset, I assume, this won't need to be backported to prev 1 or 2 (or even all) majors (versioned docs)? lmk

no I think it's ok to just have it for 0.72, so it's consistent with your other PR.

cc @Simek this one LGTM, we can merge before the 0.72 docs cut 👍

[Pranav-yadav]

Sure.
Just so that we don't miss this (apart from this PR):

P.S.: What this PR does not changes is; other npx react-native commnds such as init, upgrade, bundle, etc. Since, those commands will need proper testing before such change.

@cortinico I can open a PR for those changes (switching to yarn react-native) as well; but, I don't have proper set up to test changes such and bundle and related testing.

[Simek]

Are there any known issues related to command switch or any migration tips that we could include?

[Pranav-yadav]

Are there any known issues related to command switch or any migration tips that we could include?

As I mentioned in the PR description; specifically the table, we're only changing commands (the way we call npm scripts, also not the scripts) that everyone has been using for so long time but, no one changed it on the website 🙂,
and not changing commands that will require some testing as I've mentined in the previous comment.

[kelset]

Are there any known issues related to command switch or any migration tips that we could include?

nothing changes, we are just pointing people to the better and safer approach. Everything stays the same for the end user.

[NickGerleman]

The documentation shows separate examples for Yarn and NPM, and has tabs for when instructions are different between them.

See as an example, the usage of constants.packageManagers in getting-started.md.

This change moves instructions which currently work for any package manager, and makes them only work on yarn, outside of a yarn-specific tab.

[NickGerleman]

We're steering away from npx due to it's unreliability

I would be interested to know more about this. Is this maybe looking at npx behavior around executing remote packages?

[kelset]

Is this maybe looking at npx behavior around executing remote packages?

Not just that, also about the fact that npx means that the behaviour you get changes over time potentially, and there's the extra complication of what version of the command npx picks up based on caching and stuff... it's a minefield, so if we can avoid setting up users for useless pain it'd be much better for everyone.

[Pranav-yadav]

We're steering away from npx due to it's unreliability

I would be interested to know more about this. Is this maybe looking at npx behavior around executing remote packages?

@kelset and @cortinico can better explain this.

P.S.: Everyone can follow the "context"; link provided in PR description, for the prior relevant discussion which requested this PR.
Here: [1] react/react-native#37521 (comment)
[2] react/react-native#37521 (comment)

[NickGerleman]

Is this maybe looking at npx behavior around executing remote packages?

Not just that, also about the fact that npx means that the behaviour you get changes over time potentially, and there's the extra complication of what version of the command npx picks up based on caching and stuff... it's a minefield, so if we can avoid setting up users for useless pain it'd be much better for everyone.

This is not applicable to using npx to run local scripts.

[kelset]

Care to expand and put links to back what you are trying to say? I am not sure I understand. My point is that npx is complicated and unreliable, and I'd rather not set people approaching react-native for the first time to having to deal with something like that.

[Pranav-yadav]

I'll be taking a break, since finished with exams and haven't taken one in a while 😅.
I've "Allowed edits by maintainers". So, please "feel free to suggest and commit changes" as you feel right.
Thanks for reviewing and providing feedback

[NickGerleman]

Care to expand and put links to back what you are trying to say? I am not sure I understand. My point is that npx is complicated and unreliable, and I'd rather not set people approaching react-native for the first time to having to deal with something like that.

I think "Let's not recommend npx because it's unreliable" is misguided and not really accurate. The issue that I'm guessing this roots from was around running npx react-native init and it possibly not fetching the latest version?

Apart from imo being more a CLI bug, this scenario is specific to using npx to dowload and execute remote packages, a functionality that is fully distinct from using it for executing something already installed. Node 16+ has made that separation in the command clearer too, requiring acknowledgement any time something remote is executed. npx is still the de-facto way to portably execute an installed bin entry.

I'm also not sure switching out a confined part to yarn helps at all with the goal of "discourage npx", since right before this we tell people to use npx to init their app, in the "problematic" case of npx remote fetch. And in this case there isn't an alternative.

[NickGerleman]

With all that said, if we want to encourage running the package.json steps instead, I think recommending “yarn” and “npm run” is fine.

Intersecting with the README, IIRC it is a documented flow to initialize a project using npm, so we’d want to double check those users get the right commands in their new project README.

[kelset]

@NickGerleman let me try to recap what I think we might have reached as an agreement for what we want to document to the users (both here and in the other PR react/react-native#37521):

• npx is kept for the init command in the form of npx react-native@latest init ...
• for all the other commands that are locally available in the package.json of the template like android, ios, start, etc, we will change the docs to yarn/npm run

This sounds good to me, let us know so that we have ✅ and we can let @Pranav-yadav complete this work (sorry it's taking so long Pranav 🙇‍♂️)

[NickGerleman]

We can do that. See the examples in #3732 (review) for how to provide different tabs for npm vs yarn on the website.

Then see https://github.com/react-native-community/cli/blob/cd981848a50565cf416fbf60d0b66720f6ddd511/packages/cli/src/commands/init/init.ts#L29 for the entrypoint to CLI code for building a new project which uses npm instead of yarn. In that case, the README in the newly generated project would need to tell users to use npm run instead of the yarn commands.

[Pranav-yadav]

Sure. Will take a look at it day-after-tomorrow.

^{P.S.: Busy with an interview tomorrow :)}

[Pranav-yadav]

@NickGerleman@kelset added separate tabs for npm run and yarn commands.
^{Edit 2: Removed this completely. --> P.S.: Left a few inline comments for you. <-- Edit: Please ignore those comments as those changes are out-of-scope for this PR, will do a follow-up PR if required :) as those changes will need more discussion.}

Also, added markdown touchups wherever necessary, such as adding ``` blocks for codes that were formatted using TABs and language formatting such as ```xml

[Pranav-yadav]

Following are the live deployed preview — direct links for the changes made in this PR 😇
Make sure you check all the OS, Languages, and Package Manager Tabs 👍:

1. https://deploy-preview-3732--react-native.netlify.app/docs/next/environment-setup?guide=native#development-os
2. https://deploy-preview-3732--react-native.netlify.app/docs/next/integration-with-existing-apps
3. https://deploy-preview-3732--react-native.netlify.app/docs/next/running-on-device
4. https://deploy-preview-3732--react-native.netlify.app/docs/next/running-on-simulator-ios
5. https://deploy-preview-3732--react-native.netlify.app/docs/next/hermes#android
6. https://deploy-preview-3732--react-native.netlify.app/docs/next/libraries#installing-a-library
7. https://deploy-preview-3732--react-native.netlify.app/docs/next/native-modules-android#:~:text=The%20final%20step%20is%20to%20rebuild%20the%20React%20Native%20app%20so%20that%20you%20can%20have%20the%20latest%20native%20code%20(with%20your%20new%20native%20module!)%20available.%20In%20your%20command%20line%2C%20where%20the%20react%20native%20application%20is%20located%2C%20run%20the%20following%3A
8. https://deploy-preview-3732--react-native.netlify.app/docs/next/native-modules-ios#:~:text=The%20final%20step%20is%20to%20rebuild%20the%20React%20Native%20app%20so%20that%20you%20can%20have%20the%20latest%20native%20code%20(with%20your%20new%20native%20module!)%20available.%20In%20your%20command%20line%2C%20where%20the%20react%20native%20application%20is%20located%2C%20run%20the%20following%20%3A
9. https://deploy-preview-3732--react-native.netlify.app/docs/next/publishing-to-app-store#:~:text=(e.g.%20from%20the%20root%20of%20your%20project%3A%20npm%20run%20ios%20%2D%2D%20%2D%2Dmode%3D%22release%22%20or%20yarn%20ios%20%2D%2Dmode%20release).
10. https://deploy-preview-3732--react-native.netlify.app/docs/next/signed-apk-android#testing-the-release-build-of-your-app
11. https://deploy-preview-3732--react-native.netlify.app/docs/next/troubleshooting#using-a-port-other-than-8081

[NickGerleman]

Everything else here LGTM

[Pranav-yadav]

@kelset, I assume, this won't need to be backported to prev 1 or 2 (or even all) majors (versioned docs)? lmk

no I think it's ok to just have it for 0.72, so it's consistent with your other PR.

cc @Simek this one LGTM, we can merge before the 0.72 docs cut 👍

-- #3732 (comment)

Reminder; so we don't forget to merge this before the 0.72 cut 👍

Also, since this PR ended up being a generic sitewide change, this should not be blocked by the other RN PR :)

[kelset]

@Simek now that Nick gave his ✅ we can go ahead and merge this

[Simek]

LGTM, thank you for all the updates and work put into improving those command in the first place! 👍

[kelset]

🎉🎉🎉

[Pranav-yadav]

Thank you very much @kelset, @NickGerleman & @Simek ❤️ for your feedback and reviews.
PRs like this one have been teaching me a lot about having patience and thinking about the overall system and not just focusing on the ultimate goal.

[Pranav-yadav]

Summary

We're steering away from npx due to its unreliability and switching to npm run and yarn instead, for package.json scripts.

e.g.:

npm Tab	yarn Tab

RN Main PR: react/react-native#37521

Context

This was discussed here: react/react-native#37521 (comment)

---

P.S.: What this PR does not changes is; other npx react-native commands such as init, upgrade, bundle, etc. Since, those commands will need proper testing before such change.

[netlify]

✅ Deploy Preview for react-native ready!

Name	Link
🔨 Latest commit	f93553f
🔍 Latest deploy log	https://app.netlify.com/sites/react-native/deploys/64887cd42811b30007cfda8a
😎 Deploy Preview	https://deploy-preview-3732--react-native.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[Pranav-yadav]

@kelset, I assume, this won't need to be backported to prev 1 or 2 (or even all) majors (versioned docs)?
lmk

[kelset]

@kelset, I assume, this won't need to be backported to prev 1 or 2 (or even all) majors (versioned docs)? lmk

no I think it's ok to just have it for 0.72, so it's consistent with your other PR.

cc @Simek this one LGTM, we can merge before the 0.72 docs cut 👍

[Pranav-yadav]

Sure.
Just so that we don't miss this (apart from this PR):

P.S.: What this PR does not changes is; other npx react-native commnds such as init, upgrade, bundle, etc. Since, those commands will need proper testing before such change.

@cortinico I can open a PR for those changes (switching to yarn react-native) as well; but, I don't have proper set up to test changes such and bundle and related testing.

[Simek]

Are there any known issues related to command switch or any migration tips that we could include?

[Pranav-yadav]

Are there any known issues related to command switch or any migration tips that we could include?

As I mentioned in the PR description; specifically the table, we're only changing commands (the way we call npm scripts, also not the scripts) that everyone has been using for so long time but, no one changed it on the website 🙂,
and not changing commands that will require some testing as I've mentined in the previous comment.

[kelset]

Are there any known issues related to command switch or any migration tips that we could include?

nothing changes, we are just pointing people to the better and safer approach. Everything stays the same for the end user.

[NickGerleman]

The documentation shows separate examples for Yarn and NPM, and has tabs for when instructions are different between them.

See as an example, the usage of constants.packageManagers in getting-started.md.

This change moves instructions which currently work for any package manager, and makes them only work on yarn, outside of a yarn-specific tab.

[NickGerleman]

We're steering away from npx due to it's unreliability

I would be interested to know more about this. Is this maybe looking at npx behavior around executing remote packages?

[kelset]

Is this maybe looking at npx behavior around executing remote packages?

Not just that, also about the fact that npx means that the behaviour you get changes over time potentially, and there's the extra complication of what version of the command npx picks up based on caching and stuff... it's a minefield, so if we can avoid setting up users for useless pain it'd be much better for everyone.

[Pranav-yadav]

We're steering away from npx due to it's unreliability

I would be interested to know more about this. Is this maybe looking at npx behavior around executing remote packages?

@kelset and @cortinico can better explain this.

P.S.: Everyone can follow the "context"; link provided in PR description, for the prior relevant discussion which requested this PR.
Here: [1] react/react-native#37521 (comment)
[2] react/react-native#37521 (comment)

[NickGerleman]

Is this maybe looking at npx behavior around executing remote packages?

Not just that, also about the fact that npx means that the behaviour you get changes over time potentially, and there's the extra complication of what version of the command npx picks up based on caching and stuff... it's a minefield, so if we can avoid setting up users for useless pain it'd be much better for everyone.

This is not applicable to using npx to run local scripts.

[kelset]

Care to expand and put links to back what you are trying to say? I am not sure I understand. My point is that npx is complicated and unreliable, and I'd rather not set people approaching react-native for the first time to having to deal with something like that.

[Pranav-yadav]

I'll be taking a break, since finished with exams and haven't taken one in a while 😅.
I've "Allowed edits by maintainers". So, please "feel free to suggest and commit changes" as you feel right.
Thanks for reviewing and providing feedback

[NickGerleman]

Care to expand and put links to back what you are trying to say? I am not sure I understand. My point is that npx is complicated and unreliable, and I'd rather not set people approaching react-native for the first time to having to deal with something like that.

I think "Let's not recommend npx because it's unreliable" is misguided and not really accurate. The issue that I'm guessing this roots from was around running npx react-native init and it possibly not fetching the latest version?

Apart from imo being more a CLI bug, this scenario is specific to using npx to dowload and execute remote packages, a functionality that is fully distinct from using it for executing something already installed. Node 16+ has made that separation in the command clearer too, requiring acknowledgement any time something remote is executed. npx is still the de-facto way to portably execute an installed bin entry.

I'm also not sure switching out a confined part to yarn helps at all with the goal of "discourage npx", since right before this we tell people to use npx to init their app, in the "problematic" case of npx remote fetch. And in this case there isn't an alternative.

[NickGerleman]

With all that said, if we want to encourage running the package.json steps instead, I think recommending “yarn” and “npm run” is fine.

Intersecting with the README, IIRC it is a documented flow to initialize a project using npm, so we’d want to double check those users get the right commands in their new project README.

[kelset]

@NickGerleman let me try to recap what I think we might have reached as an agreement for what we want to document to the users (both here and in the other PR react/react-native#37521):

• npx is kept for the init command in the form of npx react-native@latest init ...
• for all the other commands that are locally available in the package.json of the template like android, ios, start, etc, we will change the docs to yarn/npm run

This sounds good to me, let us know so that we have ✅ and we can let @Pranav-yadav complete this work (sorry it's taking so long Pranav 🙇‍♂️)

[NickGerleman]

We can do that. See the examples in #3732 (review) for how to provide different tabs for npm vs yarn on the website.

Then see https://github.com/react-native-community/cli/blob/cd981848a50565cf416fbf60d0b66720f6ddd511/packages/cli/src/commands/init/init.ts#L29 for the entrypoint to CLI code for building a new project which uses npm instead of yarn. In that case, the README in the newly generated project would need to tell users to use npm run instead of the yarn commands.

[Pranav-yadav]

Sure. Will take a look at it day-after-tomorrow.

^{P.S.: Busy with an interview tomorrow :)}

[Pranav-yadav]

@NickGerleman@kelset added separate tabs for npm run and yarn commands.
^{Edit 2: Removed this completely. --> P.S.: Left a few inline comments for you. <-- Edit: Please ignore those comments as those changes are out-of-scope for this PR, will do a follow-up PR if required :) as those changes will need more discussion.}

Also, added markdown touchups wherever necessary, such as adding ``` blocks for codes that were formatted using TABs and language formatting such as ```xml

[Pranav-yadav]

Following are the live deployed preview — direct links for the changes made in this PR 😇
Make sure you check all the OS, Languages, and Package Manager Tabs 👍:

1. https://deploy-preview-3732--react-native.netlify.app/docs/next/environment-setup?guide=native#development-os
2. https://deploy-preview-3732--react-native.netlify.app/docs/next/integration-with-existing-apps
3. https://deploy-preview-3732--react-native.netlify.app/docs/next/running-on-device
4. https://deploy-preview-3732--react-native.netlify.app/docs/next/running-on-simulator-ios
5. https://deploy-preview-3732--react-native.netlify.app/docs/next/hermes#android
6. https://deploy-preview-3732--react-native.netlify.app/docs/next/libraries#installing-a-library
7. https://deploy-preview-3732--react-native.netlify.app/docs/next/native-modules-android#:~:text=The%20final%20step%20is%20to%20rebuild%20the%20React%20Native%20app%20so%20that%20you%20can%20have%20the%20latest%20native%20code%20(with%20your%20new%20native%20module!)%20available.%20In%20your%20command%20line%2C%20where%20the%20react%20native%20application%20is%20located%2C%20run%20the%20following%3A
8. https://deploy-preview-3732--react-native.netlify.app/docs/next/native-modules-ios#:~:text=The%20final%20step%20is%20to%20rebuild%20the%20React%20Native%20app%20so%20that%20you%20can%20have%20the%20latest%20native%20code%20(with%20your%20new%20native%20module!)%20available.%20In%20your%20command%20line%2C%20where%20the%20react%20native%20application%20is%20located%2C%20run%20the%20following%20%3A
9. https://deploy-preview-3732--react-native.netlify.app/docs/next/publishing-to-app-store#:~:text=(e.g.%20from%20the%20root%20of%20your%20project%3A%20npm%20run%20ios%20%2D%2D%20%2D%2Dmode%3D%22release%22%20or%20yarn%20ios%20%2D%2Dmode%20release).
10. https://deploy-preview-3732--react-native.netlify.app/docs/next/signed-apk-android#testing-the-release-build-of-your-app
11. https://deploy-preview-3732--react-native.netlify.app/docs/next/troubleshooting#using-a-port-other-than-8081

[NickGerleman]

Everything else here LGTM

[Pranav-yadav]

@kelset, I assume, this won't need to be backported to prev 1 or 2 (or even all) majors (versioned docs)? lmk

no I think it's ok to just have it for 0.72, so it's consistent with your other PR.

cc @Simek this one LGTM, we can merge before the 0.72 docs cut 👍

-- #3732 (comment)

Reminder; so we don't forget to merge this before the 0.72 cut 👍

Also, since this PR ended up being a generic sitewide change, this should not be blocked by the other RN PR :)

[kelset]

@Simek now that Nick gave his ✅ we can go ahead and merge this

[Simek]

LGTM, thank you for all the updates and work put into improving those command in the first place! 👍

[kelset]

🎉🎉🎉

[Pranav-yadav]

Thank you very much @kelset, @NickGerleman & @Simek ❤️ for your feedback and reviews.
PRs like this one have been teaching me a lot about having patience and thinking about the overall system and not just focusing on the ultimate goal.

[Pranav-yadav]

Summary

We're steering away from npx due to its unreliability and switching to npm run and yarn instead, for package.json scripts.

e.g.:

npm Tab	yarn Tab

RN Main PR: react/react-native#37521

Context

This was discussed here: react/react-native#37521 (comment)

---

P.S.: What this PR does not changes is; other npx react-native commands such as init, upgrade, bundle, etc. Since, those commands will need proper testing before such change.

[netlify]

✅ Deploy Preview for react-native ready!

Name	Link
🔨 Latest commit	f93553f
🔍 Latest deploy log	https://app.netlify.com/sites/react-native/deploys/64887cd42811b30007cfda8a
😎 Deploy Preview	https://deploy-preview-3732--react-native.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[Pranav-yadav]

@kelset, I assume, this won't need to be backported to prev 1 or 2 (or even all) majors (versioned docs)?
lmk

[kelset]

@kelset, I assume, this won't need to be backported to prev 1 or 2 (or even all) majors (versioned docs)? lmk

no I think it's ok to just have it for 0.72, so it's consistent with your other PR.

cc @Simek this one LGTM, we can merge before the 0.72 docs cut 👍

[Pranav-yadav]

Sure.
Just so that we don't miss this (apart from this PR):

P.S.: What this PR does not changes is; other npx react-native commnds such as init, upgrade, bundle, etc. Since, those commands will need proper testing before such change.

@cortinico I can open a PR for those changes (switching to yarn react-native) as well; but, I don't have proper set up to test changes such and bundle and related testing.

[Simek]

Are there any known issues related to command switch or any migration tips that we could include?

[Pranav-yadav]

Are there any known issues related to command switch or any migration tips that we could include?

As I mentioned in the PR description; specifically the table, we're only changing commands (the way we call npm scripts, also not the scripts) that everyone has been using for so long time but, no one changed it on the website 🙂,
and not changing commands that will require some testing as I've mentined in the previous comment.

[kelset]

Are there any known issues related to command switch or any migration tips that we could include?

nothing changes, we are just pointing people to the better and safer approach. Everything stays the same for the end user.

[NickGerleman]

The documentation shows separate examples for Yarn and NPM, and has tabs for when instructions are different between them.

See as an example, the usage of constants.packageManagers in getting-started.md.

This change moves instructions which currently work for any package manager, and makes them only work on yarn, outside of a yarn-specific tab.

[NickGerleman]

We're steering away from npx due to it's unreliability

I would be interested to know more about this. Is this maybe looking at npx behavior around executing remote packages?

[kelset]

Is this maybe looking at npx behavior around executing remote packages?

Not just that, also about the fact that npx means that the behaviour you get changes over time potentially, and there's the extra complication of what version of the command npx picks up based on caching and stuff... it's a minefield, so if we can avoid setting up users for useless pain it'd be much better for everyone.

[Pranav-yadav]

We're steering away from npx due to it's unreliability

I would be interested to know more about this. Is this maybe looking at npx behavior around executing remote packages?

@kelset and @cortinico can better explain this.

P.S.: Everyone can follow the "context"; link provided in PR description, for the prior relevant discussion which requested this PR.
Here: [1] react/react-native#37521 (comment)
[2] react/react-native#37521 (comment)

[NickGerleman]

Is this maybe looking at npx behavior around executing remote packages?

Not just that, also about the fact that npx means that the behaviour you get changes over time potentially, and there's the extra complication of what version of the command npx picks up based on caching and stuff... it's a minefield, so if we can avoid setting up users for useless pain it'd be much better for everyone.

This is not applicable to using npx to run local scripts.

[kelset]

Care to expand and put links to back what you are trying to say? I am not sure I understand. My point is that npx is complicated and unreliable, and I'd rather not set people approaching react-native for the first time to having to deal with something like that.

[Pranav-yadav]

I'll be taking a break, since finished with exams and haven't taken one in a while 😅.
I've "Allowed edits by maintainers". So, please "feel free to suggest and commit changes" as you feel right.
Thanks for reviewing and providing feedback

[NickGerleman]

Care to expand and put links to back what you are trying to say? I am not sure I understand. My point is that npx is complicated and unreliable, and I'd rather not set people approaching react-native for the first time to having to deal with something like that.

I think "Let's not recommend npx because it's unreliable" is misguided and not really accurate. The issue that I'm guessing this roots from was around running npx react-native init and it possibly not fetching the latest version?

Apart from imo being more a CLI bug, this scenario is specific to using npx to dowload and execute remote packages, a functionality that is fully distinct from using it for executing something already installed. Node 16+ has made that separation in the command clearer too, requiring acknowledgement any time something remote is executed. npx is still the de-facto way to portably execute an installed bin entry.

I'm also not sure switching out a confined part to yarn helps at all with the goal of "discourage npx", since right before this we tell people to use npx to init their app, in the "problematic" case of npx remote fetch. And in this case there isn't an alternative.

[NickGerleman]

With all that said, if we want to encourage running the package.json steps instead, I think recommending “yarn” and “npm run” is fine.

Intersecting with the README, IIRC it is a documented flow to initialize a project using npm, so we’d want to double check those users get the right commands in their new project README.

[kelset]

@NickGerleman let me try to recap what I think we might have reached as an agreement for what we want to document to the users (both here and in the other PR react/react-native#37521):

• npx is kept for the init command in the form of npx react-native@latest init ...
• for all the other commands that are locally available in the package.json of the template like android, ios, start, etc, we will change the docs to yarn/npm run

This sounds good to me, let us know so that we have ✅ and we can let @Pranav-yadav complete this work (sorry it's taking so long Pranav 🙇‍♂️)

[NickGerleman]

We can do that. See the examples in #3732 (review) for how to provide different tabs for npm vs yarn on the website.

Then see https://github.com/react-native-community/cli/blob/cd981848a50565cf416fbf60d0b66720f6ddd511/packages/cli/src/commands/init/init.ts#L29 for the entrypoint to CLI code for building a new project which uses npm instead of yarn. In that case, the README in the newly generated project would need to tell users to use npm run instead of the yarn commands.

[Pranav-yadav]

Sure. Will take a look at it day-after-tomorrow.

^{P.S.: Busy with an interview tomorrow :)}

[Pranav-yadav]

@NickGerleman@kelset added separate tabs for npm run and yarn commands.
^{Edit 2: Removed this completely. --> P.S.: Left a few inline comments for you. <-- Edit: Please ignore those comments as those changes are out-of-scope for this PR, will do a follow-up PR if required :) as those changes will need more discussion.}

Also, added markdown touchups wherever necessary, such as adding ``` blocks for codes that were formatted using TABs and language formatting such as ```xml

[Pranav-yadav]

Following are the live deployed preview — direct links for the changes made in this PR 😇
Make sure you check all the OS, Languages, and Package Manager Tabs 👍:

1. https://deploy-preview-3732--react-native.netlify.app/docs/next/environment-setup?guide=native#development-os
2. https://deploy-preview-3732--react-native.netlify.app/docs/next/integration-with-existing-apps
3. https://deploy-preview-3732--react-native.netlify.app/docs/next/running-on-device
4. https://deploy-preview-3732--react-native.netlify.app/docs/next/running-on-simulator-ios
5. https://deploy-preview-3732--react-native.netlify.app/docs/next/hermes#android
6. https://deploy-preview-3732--react-native.netlify.app/docs/next/libraries#installing-a-library
7. https://deploy-preview-3732--react-native.netlify.app/docs/next/native-modules-android#:~:text=The%20final%20step%20is%20to%20rebuild%20the%20React%20Native%20app%20so%20that%20you%20can%20have%20the%20latest%20native%20code%20(with%20your%20new%20native%20module!)%20available.%20In%20your%20command%20line%2C%20where%20the%20react%20native%20application%20is%20located%2C%20run%20the%20following%3A
8. https://deploy-preview-3732--react-native.netlify.app/docs/next/native-modules-ios#:~:text=The%20final%20step%20is%20to%20rebuild%20the%20React%20Native%20app%20so%20that%20you%20can%20have%20the%20latest%20native%20code%20(with%20your%20new%20native%20module!)%20available.%20In%20your%20command%20line%2C%20where%20the%20react%20native%20application%20is%20located%2C%20run%20the%20following%20%3A
9. https://deploy-preview-3732--react-native.netlify.app/docs/next/publishing-to-app-store#:~:text=(e.g.%20from%20the%20root%20of%20your%20project%3A%20npm%20run%20ios%20%2D%2D%20%2D%2Dmode%3D%22release%22%20or%20yarn%20ios%20%2D%2Dmode%20release).
10. https://deploy-preview-3732--react-native.netlify.app/docs/next/signed-apk-android#testing-the-release-build-of-your-app
11. https://deploy-preview-3732--react-native.netlify.app/docs/next/troubleshooting#using-a-port-other-than-8081

[NickGerleman]

Everything else here LGTM

[Pranav-yadav]

@kelset, I assume, this won't need to be backported to prev 1 or 2 (or even all) majors (versioned docs)? lmk

no I think it's ok to just have it for 0.72, so it's consistent with your other PR.

cc @Simek this one LGTM, we can merge before the 0.72 docs cut 👍

-- #3732 (comment)

Reminder; so we don't forget to merge this before the 0.72 cut 👍

Also, since this PR ended up being a generic sitewide change, this should not be blocked by the other RN PR :)

[kelset]

@Simek now that Nick gave his ✅ we can go ahead and merge this

[Simek]

LGTM, thank you for all the updates and work put into improving those command in the first place! 👍

[kelset]

🎉🎉🎉

[Pranav-yadav]

Thank you very much @kelset, @NickGerleman & @Simek ❤️ for your feedback and reviews.
PRs like this one have been teaching me a lot about having patience and thinking about the overall system and not just focusing on the ultimate goal.

[Pranav-yadav]

Summary

We're steering away from npx due to its unreliability and switching to npm run and yarn instead, for package.json scripts.

e.g.:

npm Tab	yarn Tab

RN Main PR: react/react-native#37521

Context

This was discussed here: react/react-native#37521 (comment)

---

P.S.: What this PR does not changes is; other npx react-native commands such as init, upgrade, bundle, etc. Since, those commands will need proper testing before such change.

[netlify]

✅ Deploy Preview for react-native ready!

Name	Link
🔨 Latest commit	f93553f
🔍 Latest deploy log	https://app.netlify.com/sites/react-native/deploys/64887cd42811b30007cfda8a
😎 Deploy Preview	https://deploy-preview-3732--react-native.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[Pranav-yadav]

@kelset, I assume, this won't need to be backported to prev 1 or 2 (or even all) majors (versioned docs)?
lmk

[kelset]

@kelset, I assume, this won't need to be backported to prev 1 or 2 (or even all) majors (versioned docs)? lmk

no I think it's ok to just have it for 0.72, so it's consistent with your other PR.

cc @Simek this one LGTM, we can merge before the 0.72 docs cut 👍

[Pranav-yadav]

Sure.
Just so that we don't miss this (apart from this PR):

P.S.: What this PR does not changes is; other npx react-native commnds such as init, upgrade, bundle, etc. Since, those commands will need proper testing before such change.

@cortinico I can open a PR for those changes (switching to yarn react-native) as well; but, I don't have proper set up to test changes such and bundle and related testing.

[Simek]

Are there any known issues related to command switch or any migration tips that we could include?

[Pranav-yadav]

Are there any known issues related to command switch or any migration tips that we could include?

As I mentioned in the PR description; specifically the table, we're only changing commands (the way we call npm scripts, also not the scripts) that everyone has been using for so long time but, no one changed it on the website 🙂,
and not changing commands that will require some testing as I've mentined in the previous comment.

[kelset]

Are there any known issues related to command switch or any migration tips that we could include?

nothing changes, we are just pointing people to the better and safer approach. Everything stays the same for the end user.

[NickGerleman]

The documentation shows separate examples for Yarn and NPM, and has tabs for when instructions are different between them.

See as an example, the usage of constants.packageManagers in getting-started.md.

This change moves instructions which currently work for any package manager, and makes them only work on yarn, outside of a yarn-specific tab.

[NickGerleman]

We're steering away from npx due to it's unreliability

I would be interested to know more about this. Is this maybe looking at npx behavior around executing remote packages?

[kelset]

Is this maybe looking at npx behavior around executing remote packages?

Not just that, also about the fact that npx means that the behaviour you get changes over time potentially, and there's the extra complication of what version of the command npx picks up based on caching and stuff... it's a minefield, so if we can avoid setting up users for useless pain it'd be much better for everyone.

[Pranav-yadav]

We're steering away from npx due to it's unreliability

I would be interested to know more about this. Is this maybe looking at npx behavior around executing remote packages?

@kelset and @cortinico can better explain this.

P.S.: Everyone can follow the "context"; link provided in PR description, for the prior relevant discussion which requested this PR.
Here: [1] react/react-native#37521 (comment)
[2] react/react-native#37521 (comment)

[NickGerleman]

Is this maybe looking at npx behavior around executing remote packages?

Not just that, also about the fact that npx means that the behaviour you get changes over time potentially, and there's the extra complication of what version of the command npx picks up based on caching and stuff... it's a minefield, so if we can avoid setting up users for useless pain it'd be much better for everyone.

This is not applicable to using npx to run local scripts.

[kelset]

Care to expand and put links to back what you are trying to say? I am not sure I understand. My point is that npx is complicated and unreliable, and I'd rather not set people approaching react-native for the first time to having to deal with something like that.

[Pranav-yadav]

I'll be taking a break, since finished with exams and haven't taken one in a while 😅.
I've "Allowed edits by maintainers". So, please "feel free to suggest and commit changes" as you feel right.
Thanks for reviewing and providing feedback

[NickGerleman]

Care to expand and put links to back what you are trying to say? I am not sure I understand. My point is that npx is complicated and unreliable, and I'd rather not set people approaching react-native for the first time to having to deal with something like that.

I think "Let's not recommend npx because it's unreliable" is misguided and not really accurate. The issue that I'm guessing this roots from was around running npx react-native init and it possibly not fetching the latest version?

Apart from imo being more a CLI bug, this scenario is specific to using npx to dowload and execute remote packages, a functionality that is fully distinct from using it for executing something already installed. Node 16+ has made that separation in the command clearer too, requiring acknowledgement any time something remote is executed. npx is still the de-facto way to portably execute an installed bin entry.

I'm also not sure switching out a confined part to yarn helps at all with the goal of "discourage npx", since right before this we tell people to use npx to init their app, in the "problematic" case of npx remote fetch. And in this case there isn't an alternative.

[NickGerleman]

With all that said, if we want to encourage running the package.json steps instead, I think recommending “yarn” and “npm run” is fine.

Intersecting with the README, IIRC it is a documented flow to initialize a project using npm, so we’d want to double check those users get the right commands in their new project README.

[kelset]

@NickGerleman let me try to recap what I think we might have reached as an agreement for what we want to document to the users (both here and in the other PR react/react-native#37521):

• npx is kept for the init command in the form of npx react-native@latest init ...
• for all the other commands that are locally available in the package.json of the template like android, ios, start, etc, we will change the docs to yarn/npm run

This sounds good to me, let us know so that we have ✅ and we can let @Pranav-yadav complete this work (sorry it's taking so long Pranav 🙇‍♂️)

[NickGerleman]

We can do that. See the examples in #3732 (review) for how to provide different tabs for npm vs yarn on the website.

Then see https://github.com/react-native-community/cli/blob/cd981848a50565cf416fbf60d0b66720f6ddd511/packages/cli/src/commands/init/init.ts#L29 for the entrypoint to CLI code for building a new project which uses npm instead of yarn. In that case, the README in the newly generated project would need to tell users to use npm run instead of the yarn commands.

[Pranav-yadav]

Sure. Will take a look at it day-after-tomorrow.

^{P.S.: Busy with an interview tomorrow :)}

[Pranav-yadav]

@NickGerleman@kelset added separate tabs for npm run and yarn commands.
^{Edit 2: Removed this completely. --> P.S.: Left a few inline comments for you. <-- Edit: Please ignore those comments as those changes are out-of-scope for this PR, will do a follow-up PR if required :) as those changes will need more discussion.}

Also, added markdown touchups wherever necessary, such as adding ``` blocks for codes that were formatted using TABs and language formatting such as ```xml

[Pranav-yadav]

Following are the live deployed preview — direct links for the changes made in this PR 😇
Make sure you check all the OS, Languages, and Package Manager Tabs 👍:

1. https://deploy-preview-3732--react-native.netlify.app/docs/next/environment-setup?guide=native#development-os
2. https://deploy-preview-3732--react-native.netlify.app/docs/next/integration-with-existing-apps
3. https://deploy-preview-3732--react-native.netlify.app/docs/next/running-on-device
4. https://deploy-preview-3732--react-native.netlify.app/docs/next/running-on-simulator-ios
5. https://deploy-preview-3732--react-native.netlify.app/docs/next/hermes#android
6. https://deploy-preview-3732--react-native.netlify.app/docs/next/libraries#installing-a-library
7. https://deploy-preview-3732--react-native.netlify.app/docs/next/native-modules-android#:~:text=The%20final%20step%20is%20to%20rebuild%20the%20React%20Native%20app%20so%20that%20you%20can%20have%20the%20latest%20native%20code%20(with%20your%20new%20native%20module!)%20available.%20In%20your%20command%20line%2C%20where%20the%20react%20native%20application%20is%20located%2C%20run%20the%20following%3A
8. https://deploy-preview-3732--react-native.netlify.app/docs/next/native-modules-ios#:~:text=The%20final%20step%20is%20to%20rebuild%20the%20React%20Native%20app%20so%20that%20you%20can%20have%20the%20latest%20native%20code%20(with%20your%20new%20native%20module!)%20available.%20In%20your%20command%20line%2C%20where%20the%20react%20native%20application%20is%20located%2C%20run%20the%20following%20%3A
9. https://deploy-preview-3732--react-native.netlify.app/docs/next/publishing-to-app-store#:~:text=(e.g.%20from%20the%20root%20of%20your%20project%3A%20npm%20run%20ios%20%2D%2D%20%2D%2Dmode%3D%22release%22%20or%20yarn%20ios%20%2D%2Dmode%20release).
10. https://deploy-preview-3732--react-native.netlify.app/docs/next/signed-apk-android#testing-the-release-build-of-your-app
11. https://deploy-preview-3732--react-native.netlify.app/docs/next/troubleshooting#using-a-port-other-than-8081

[NickGerleman]

Everything else here LGTM

[Pranav-yadav]

@kelset, I assume, this won't need to be backported to prev 1 or 2 (or even all) majors (versioned docs)? lmk

no I think it's ok to just have it for 0.72, so it's consistent with your other PR.

cc @Simek this one LGTM, we can merge before the 0.72 docs cut 👍

-- #3732 (comment)

Reminder; so we don't forget to merge this before the 0.72 cut 👍

Also, since this PR ended up being a generic sitewide change, this should not be blocked by the other RN PR :)

[kelset]

@Simek now that Nick gave his ✅ we can go ahead and merge this

[Simek]

LGTM, thank you for all the updates and work put into improving those command in the first place! 👍

[kelset]

🎉🎉🎉

[Pranav-yadav]

Thank you very much @kelset, @NickGerleman & @Simek ❤️ for your feedback and reviews.
PRs like this one have been teaching me a lot about having patience and thinking about the overall system and not just focusing on the ultimate goal.