Background
I'm actively working on preparing a react-native monorepo template with enabled hoisting.
I've everything working besides one thing.
When I'm running react-native run-android packager is starting from monorepo root(./) instead of app package ./apps/app
I can workaround it by running packager upfront but I would love to have that template working without such workarounds.
Findings
I've dived deeply into how I can work around it and figured out that there is no option to solve that without patching react-native.
Why is that?
Current flow
Currently running packager for run-android is working the following way:
- CLI is calling startServerInNewWindow
startServerInNewWindow
lauchPackager.sh is calling packager.sh
packager.sh is calling react-native start from PROJECT_ROOT which is statically set to the path relative to node_modules/react-native
Why is that a problem?
-
Currently the simplest option to change PROJECT_ROOT from CLI perspective is to overwrite PROJECT_ROOT environment variable inside .packager.env
- In the currently released react-native 0.71
packager.sh is always overwriting PROJECT_ROOT path with a path relative to the script location.
- In future version(react-native master) there it accepts
PROJECT_ROOT from outside.
- Sadly there is still this condition that will overwrite this path because in monorepo we have hoisting so the react-native package is located in monorepo root instead
PROJECT_ROOT
-
Generally configuration of react-native start from CLI perspective is limited.
It seems that packager.sh accepts additional arguments (with "$@" at the end) that will be forwarded to react-native start.
However launchPackager.command is not forwarding it from CLI
Question
-
I'm curious what is the story behind this solution where CLI have to call react-native internal script that will call CLI.
Maybe there is someone who has some background on this one?
-
Is this script treated internally in react-native as something that should be used by the community?
This question is based on this comment inside packager.sh that sounds like it is something for internal react-native testing.
-
If this is something that should be used by the community then I'm wondering if there is a way to make it more configurable from a CLI perspective.
Reproducible demo:
Background
I'm actively working on preparing a react-native monorepo template with enabled hoisting.
I've everything working besides one thing.
When I'm running
react-native run-androidpackager is starting from monorepo root(./) instead of app package./apps/appI can workaround it by running packager upfront but I would love to have that template working without such workarounds.
Findings
I've dived deeply into how I can work around it and figured out that there is no option to solve that without patching
react-native.Why is that?
Current flow
Currently running packager for
run-androidis working the following way:startServerInNewWindow.packager.envlauchPackager.shis calling packager.shpackager.shis callingreact-native startfromPROJECT_ROOTwhich is statically set to the path relative tonode_modules/react-nativeWhy is that a problem?
Currently the simplest option to change
PROJECT_ROOTfrom CLI perspective is to overwritePROJECT_ROOTenvironment variable inside.packager.envpackager.shis always overwritingPROJECT_ROOTpath with a path relative to the script location.PROJECT_ROOTfrom outside.PROJECT_ROOTGenerally configuration of
react-native startfromCLIperspective is limited.It seems that
packager.shaccepts additional arguments (with"$@"at the end) that will be forwarded toreact-native start.However
launchPackager.commandis not forwarding it fromCLIQuestion
I'm curious what is the story behind this solution where
CLIhave to callreact-native internal scriptthat will callCLI.Maybe there is someone who has some background on this one?
Is this script treated internally in react-native as something that should be used by the community?
This question is based on this comment inside
packager.shthat sounds like it is something for internal react-native testing.If this is something that should be used by the community then I'm wondering if there is a way to make it more configurable from a
CLIperspective.Reproducible demo:
yarn android(doesn't matter if you will do that from app directory or root)