RFC: out-of-NPM package solution for React Native Artifacts #508
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
cortinico
added a commit
to cortinico/react-native
that referenced
this pull request
Sep 28, 2022
Summary: I'm not going to merge this as it is, this is mostly for discussions with the community for the sake of RFC facebook#508 react-native-community/discussions-and-proposals#508 Here I'm setting up a :ReactAndroid:external-artifacts Gradle module which is responsible of uploading arbitrary artifacts to Maven (Central or any other repo). In this specific example I'm uploading the Hermes iOS tarball which is 500+ Mb. In this module I've configured the auth with Sonatype for publishing and the GPG signing of the artifacts. Changelog: [Internal] [Changed] - Store the iOS Hermes tarball on Maven Differential Revision: D39886167 fbshipit-source-id: 66edae7f83df35525dc8cccd68bb5bb3a5e02a12
kelset
reviewed
Sep 29, 2022
kelset
reviewed
Sep 29, 2022
UpdateHey all,
I've updated the RFC with the considerations from those 2 prototype. At this stage we're leaning towards the Maven approach. We're still allowing some days to collect feedbacks before making a final decision which will most likely land on 0.71.0. |
Kudo
reviewed
Sep 29, 2022
This was referenced Oct 1, 2022
Closed
Co-authored-by: Lorenzo Sciandra <lorenzo.sciandra@gmail.com>
cortinico
force-pushed
the
nc/out-of-npm-rfc
branch
from
606448c
to
4a06fc6
Compare
|
This can now be merged (cc @kelset and others for approvals) |
kelset
approved these changes
Dec 8, 2022
4 tasks
|
react-native-quick-sqlite is broken due to this. |
|
This method makes it impossible to integrate RN in the existing projects of Android, and can only use the old version of React-Native, which is really bad |
That's not correct. Actually, this method makes 'easier' to integrate with existing Android apps as we're now shipping artifacts to Maven Central, where a lot of other popular Android libraries are living. @mazhuang123 Can you elaborate on what is your problem? |
This is not the right repo to ask for support to your specific question. |
jakubgs
added a commit
to status-im/status-mobile
that referenced
this pull request
Aug 31, 2023
Before what we did was essentially guess what files might exist for any given package. This approach mostly works, but not entirely. This is especially problematic when dealing with weird edge case packages like `react-native`, which you can read about here: react-native-community/discussions-and-proposals#508 https://github.com/react-native-community/discussions-and-proposals/blob/4a06fc64/proposals/0508-out-of-npm-artifacts.md#the-react-native-android-archive In order to avoid as much the guessing aspect of fetching Gradle dependencies we are using both HTML listsings of files and `artifact-metadata.json` files that exist for more recent packages. This way we can avoid having to add special edge cases that have been found out when working on React Native 72 upgrade in: #17062 Signed-off-by: Jakub Sokołowski <jakub@status.im>
jakubgs
added a commit
to status-im/status-mobile
that referenced
this pull request
Aug 31, 2023
Before what we did was essentially guess what files might exist for any given package. This approach mostly works, but not entirely. This is especially problematic when dealing with weird edge case packages like `react-native`, which you can read about here: react-native-community/discussions-and-proposals#508 https://github.com/react-native-community/discussions-and-proposals/blob/4a06fc64/proposals/0508-out-of-npm-artifacts.md#the-react-native-android-archive In order to avoid as much the guessing aspect of fetching Gradle dependencies we are using both HTML listsings of files and `artifact-metadata.json` files that exist for more recent packages. This way we can avoid having to add special edge cases that have been found out when working on React Native 72 upgrade in: #17062 Signed-off-by: Jakub Sokołowski <jakub@status.im>
jakubgs
added a commit
to status-im/status-mobile
that referenced
this pull request
Aug 31, 2023
Before what we did was essentially guess what files might exist for any given package. This approach mostly works, but not entirely. This is especially problematic when dealing with weird edge case packages like `react-native`, which you can read about here: react-native-community/discussions-and-proposals#508 https://github.com/react-native-community/discussions-and-proposals/blob/4a06fc64/proposals/0508-out-of-npm-artifacts.md#the-react-native-android-archive In order to avoid as much the guessing aspect of fetching Gradle dependencies we are using both HTML listsings of files and `artifact-metadata.json` files that exist for more recent packages. This way we can avoid having to add special edge cases that have been found out when working on React Native 72 upgrade in: #17062 Signed-off-by: Jakub Sokołowski <jakub@status.im>
jakubgs
added a commit
to status-im/status-mobile
that referenced
this pull request
Aug 31, 2023
Before what we did was essentially guess what files might exist for any given package. This approach mostly works, but not entirely. This is especially problematic when dealing with weird edge case packages like `react-native`, which you can read about here: react-native-community/discussions-and-proposals#508 https://github.com/react-native-community/discussions-and-proposals/blob/4a06fc64/proposals/0508-out-of-npm-artifacts.md#the-react-native-android-archive In order to avoid as much the guessing aspect of fetching Gradle dependencies we are using both HTML listsings of files and `artifact-metadata.json` files that exist for more recent packages. This way we can avoid having to add special edge cases that have been found out when working on React Native 72 upgrade in: #17062 Signed-off-by: Jakub Sokołowski <jakub@status.im>
jakubgs
added a commit
to status-im/status-mobile
that referenced
this pull request
Aug 31, 2023
Before what we did was essentially guess what files might exist for any given package. This approach mostly works, but not entirely. This is especially problematic when dealing with weird edge case packages like `react-native`, which you can read about here: react-native-community/discussions-and-proposals#508 https://github.com/react-native-community/discussions-and-proposals/blob/4a06fc64/proposals/0508-out-of-npm-artifacts.md#the-react-native-android-archive In order to avoid as much the guessing aspect of fetching Gradle dependencies we are using both HTML listsings of files and `artifact-metadata.json` files that exist for more recent packages. This way we can avoid having to add special edge cases that have been found out when working on React Native 72 upgrade in: #17062 Signed-off-by: Jakub Sokołowski <jakub@status.im>
jakubgs
added a commit
to status-im/status-mobile
that referenced
this pull request
Aug 31, 2023
Before what we did was essentially guess what files might exist for any given package. This approach mostly works, but not entirely. This is especially problematic when dealing with weird edge case packages like `react-native`, which you can read about here: react-native-community/discussions-and-proposals#508 https://github.com/react-native-community/discussions-and-proposals/blob/4a06fc64/proposals/0508-out-of-npm-artifacts.md#the-react-native-android-archive In order to avoid as much the guessing aspect of fetching Gradle dependencies we are using both HTML listsings of files and `artifact-metadata.json` files that exist for more recent packages. This way we can avoid having to add special edge cases that have been found out when working on React Native 72 upgrade in: #17062 Signed-off-by: Jakub Sokołowski <jakub@status.im>
jakubgs
added a commit
to status-im/status-mobile
that referenced
this pull request
Aug 31, 2023
Before what we did was essentially guess what files might exist for any given package. This approach mostly works, but not entirely. This is especially problematic when dealing with weird edge case packages like `react-native`, which you can read about here: react-native-community/discussions-and-proposals#508 https://github.com/react-native-community/discussions-and-proposals/blob/4a06fc64/proposals/0508-out-of-npm-artifacts.md#the-react-native-android-archive In order to avoid as much the guessing aspect of fetching Gradle dependencies we are using both HTML listsings of files and `artifact-metadata.json` files that exist for more recent packages. This way we can avoid having to add special edge cases that have been found out when working on React Native 72 upgrade in: #17062 Signed-off-by: Jakub Sokołowski <jakub@status.im>
jakubgs
added a commit
to status-im/status-mobile
that referenced
this pull request
Sep 4, 2023
Before what we did was essentially guess what files might exist for any given package. This approach mostly works, but not entirely. This is especially problematic when dealing with weird edge case packages like `react-native`, which you can read about here: react-native-community/discussions-and-proposals#508 https://github.com/react-native-community/discussions-and-proposals/blob/4a06fc64/proposals/0508-out-of-npm-artifacts.md#the-react-native-android-archive In order to avoid as much the guessing aspect of fetching Gradle dependencies we are using both HTML listsings of files and `artifact-metadata.json` files that exist for more recent packages. This way we can avoid having to add special edge cases that have been found out when working on React Native 72 upgrade in: #17062 Signed-off-by: Jakub Sokołowski <jakub@status.im>
jakubgs
added a commit
to status-im/status-mobile
that referenced
this pull request
Sep 4, 2023
Before what we did was essentially guess what files might exist for any given package. This approach mostly works, but not entirely. This is especially problematic when dealing with weird edge case packages like `react-native`, which you can read about here: react-native-community/discussions-and-proposals#508 https://github.com/react-native-community/discussions-and-proposals/blob/4a06fc64/proposals/0508-out-of-npm-artifacts.md#the-react-native-android-archive In order to avoid as much the guessing aspect of fetching Gradle dependencies we are using both HTML listsings of files and `artifact-metadata.json` files that exist for more recent packages. This way we can avoid having to add special edge cases that have been found out when working on React Native 72 upgrade in: #17062 Signed-off-by: Jakub Sokołowski <jakub@status.im>
alwx
pushed a commit
to status-im/status-mobile
that referenced
this pull request
Sep 6, 2023
Before what we did was essentially guess what files might exist for any given package. This approach mostly works, but not entirely. This is especially problematic when dealing with weird edge case packages like `react-native`, which you can read about here: react-native-community/discussions-and-proposals#508 https://github.com/react-native-community/discussions-and-proposals/blob/4a06fc64/proposals/0508-out-of-npm-artifacts.md#the-react-native-android-archive In order to avoid as much the guessing aspect of fetching Gradle dependencies we are using both HTML listsings of files and `artifact-metadata.json` files that exist for more recent packages. This way we can avoid having to add special edge cases that have been found out when working on React Native 72 upgrade in: #17062 Signed-off-by: Jakub Sokołowski <jakub@status.im>
|
Is there a way to see the discussion links referenced above like: https://github.com/react-native-community/discussions-and-proposals/blob/nc/out-of-npm-rfc/proposals/0000-out-of-npm-artifacts.md#prototype. I’m trying to make some boilerplate for a JSI plugin and having some issues with the Android procedure. |
|
@therealpurplemana I think this is the link you are talking about? facebook/react-native#34812 you can check them out via: https://github.com/react-native-community/discussions-and-proposals/pull/508/files |
|
Thank you |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hey all,
I'm sharing this RFC I wrote with the support of @renchap & @kelset to solve the problem of our NPM package size. We would love to hear the community's opinion on this change before we take any step in any direction.
We don't believe this change will affect users of React Native but will most likely affect advanced users such as library developers, SDK authors, developers of out-of-tree platforms that rely on our artifacts.
For a better reading experience you can find the file view here.