-
Notifications
You must be signed in to change notification settings - Fork 24.3k
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.
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
Android template: Allow overriding default "index.js" entry file #26769
Conversation
I think it's best to do it in react.build file. |
Good point, I'll update PR with this change. @dulmandakh Updated. |
- Using "System.getenv" allows to specify any entry file using environment variables and without modifying gradle file. Example: export ENTRY_FILE="another_entry_file.js" ./gradlew assembleDebug - This functionality is also more align with iOS implementation that uses 'if [[ "$ENTRY_FILE" ]]; then'. See #23667 for more details.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not a big fan of this functionality if I'm being honest because we could just toggle the entry point within index.js
using the Platform
module without needing more build configuration.
Making it consistent with iOS makes sense to me, though. Thanks for the PR!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cpojer is landing this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
This pull request was successfully merged by Maksym Rusynyk in a0d8740. When will my fix make it into a release? | Upcoming Releases |
Part of the RN v0.61 -> v0.62 changes to the template app [1], corresponding to facebook/react-native@a0d874087. This must happen at or after the main upgrade commit because the field is newly optional at the new version. There isn't a clear functional advantage to doing it this way. In fact, the maintainer who merged it said he was "not a big fan" of the change [2]. But he merged it anyway, on the grounds that it makes the experience more consistent with iOS. So, I suppose it does that for us, too, and in any case we're now more consistent with the template app. [1] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [2] facebook/react-native#26769 (review)
Part of the RN v0.61 -> v0.62 changes to the template app [1], corresponding to facebook/react-native@a0d874087. This must happen at or after the main upgrade commit because the field is newly optional at the new version. There isn't a clear functional advantage to doing it this way. In fact, the maintainer who merged it said he was "not a big fan" of the change [2]. But he merged it anyway, on the grounds that it makes the experience more consistent with iOS. So, I suppose it does that for us, too, and in any case we're now more consistent with the template app. [1] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [2] facebook/react-native#26769 (review)
Part of the RN v0.61 -> v0.62 changes to the template app [1], corresponding to facebook/react-native@a0d874087. This must happen at or after the main upgrade commit because the field is newly optional at the new version. There isn't a clear functional advantage to doing it this way. In fact, the maintainer who merged it said he was "not a big fan" of the change [2]. But he merged it anyway, on the grounds that it makes the experience more consistent with iOS. So, I suppose it does that for us, too, and in any case we're now more consistent with the template app. [1] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [2] facebook/react-native#26769 (review)
Part of the RN v0.61 -> v0.62 changes to the template app [1], corresponding to facebook/react-native@a0d874087. This must happen at or after the main upgrade commit because the field is newly optional at the new version. There isn't a clear functional advantage to doing it this way. In fact, the maintainer who merged it said he was "not a big fan" of the change [2]. But he merged it anyway, on the grounds that it makes the experience more consistent with iOS. So, I suppose it does that for us, too, and in any case we're now more consistent with the template app. [1] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [2] facebook/react-native#26769 (review)
Part of the RN v0.61 -> v0.62 changes to the template app [1], corresponding to facebook/react-native@a0d874087. This must happen at or after the main upgrade commit because the field is newly optional at the new version. There isn't a clear functional advantage to doing it this way. In fact, the maintainer who merged it said he was "not a big fan" of the change [2]. But he merged it anyway, on the grounds that it makes the experience more consistent with iOS. So, I suppose it does that for us, too, and in any case we're now more consistent with the template app. [1] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [2] facebook/react-native#26769 (review)
Part of the RN v0.61 -> v0.62 changes to the template app [1], corresponding to facebook/react-native@a0d874087. This must happen at or after the main upgrade commit because the field is newly optional at the new version. There isn't a clear functional advantage to doing it this way. In fact, the maintainer who merged it said he was "not a big fan" of the change [2]. But he merged it anyway, on the grounds that it makes the experience more consistent with iOS. So, I suppose it does that for us, too, and in any case we're now more consistent with the template app. [1] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [2] facebook/react-native#26769 (review)
Part of the RN v0.61 -> v0.62 changes to the template app [1], corresponding to facebook/react-native@a0d874087. This must happen at or after the main upgrade commit because the field is newly optional at the new version. There isn't a clear functional advantage to doing it this way. In fact, the maintainer who merged it said he was "not a big fan" of the change [2]. But he merged it anyway, on the grounds that it makes the experience more consistent with iOS. So, I suppose it does that for us, too, and in any case we're now more consistent with the template app. [1] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [2] facebook/react-native#26769 (review)
Part of the RN v0.61 -> v0.62 changes to the template app [1], corresponding to facebook/react-native@a0d874087. This must happen at or after the main upgrade commit because the field is newly optional at the new version. There isn't a clear functional advantage to doing it this way. In fact, the maintainer who merged it said he was "not a big fan" of the change [2]. But he merged it anyway, on the grounds that it makes the experience more consistent with iOS. So, I suppose it does that for us, too, and in any case we're now more consistent with the template app. [1] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [2] facebook/react-native#26769 (review)
Part of the RN v0.61 -> v0.62 changes to the template app [1], corresponding to facebook/react-native@a0d874087. This must happen at or after the main upgrade commit because the field is newly optional at the new version. There isn't a clear functional advantage to doing it this way. In fact, the maintainer who merged it said he was "not a big fan" of the change [2]. But he merged it anyway, on the grounds that it makes the experience more consistent with iOS. So, I suppose it does that for us, too, and in any case we're now more consistent with the template app. [1] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [2] facebook/react-native#26769 (review)
Summary
Using "System.getenv" allows to specify any entry file using environment variables and without modifying gradle file. Example:
export ENTRY_FILE="another_entry_file.js"
./gradlew assembleDebug
This functionality is also more align with iOS implementation that uses 'if [[ "$ENTRY_FILE" ]]; then'. See [iOS] [Added] - Allow overriding ENTRY_FILE on react-native-xcode.sh script #23667 for more details.
Possibility to define entry file on CI without modifying sources (Example: project like pixels-catcher requires different entry file)
Changelog
[Android] [Added] - Custom entry file on android using
ENTRY_FILE
environment variableTest Plan
Create a project from template
Define
ENTRY_FILE
environment variableExpected result: App contains bundle file that starts from
anotherIndexFile.js
file.