chore(deps): patch react-native-fs with privacy manifest #5322
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
jeanregisser
approved these changes
Apr 24, 2024
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #5322 +/- ##
=======================================
Coverage 86.08% 86.09%
=======================================
Files 747 747
Lines 30671 30671
Branches 5313 5313
=======================================
+ Hits 26403 26406 +3
+ Misses 4036 4033 -3
Partials 232 232 see 1 file with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
jophish
approved these changes
Apr 24, 2024
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
shottah
pushed a commit
to zed-io/kolektivo
that referenced
this pull request
May 15, 2024
…5322) ### Description The `react-native-fs` project is no longer maintained, and I don't have faith that a new version with the changes we need will be published. It seems like the maintainer of the project has changed but he is now publishing a fork rather than publishing from this project (context `https://github.com/itinance/react-native-fs/issues/1197`). The fork has a lot of [changes](itinance/react-native-fs@master...birdofpreyru:react-native-fs:master) and it seems that most projects have _not_ yet migrated to this fork ([low downloads on npm](https://www.npmjs.com/package/@dr.pogodin/react-native-fs)). I don't want to make a decision now about which lib to migrate to and introduce more changes than necessary given the deadline for these privacy manifest changes. So this PR contains a patch that I made for the lib, and I used the [same declared values](https://github.com/birdofpreyru/react-native-fs/blob/master/ios/PrivacyInfo.xcprivacy) as in the fork (I did also verify that the values seem reasonable). ### Test plan n/a ### Related issues - Related to RET-1058 ### Backwards compatibility Y ### Network scalability If a new NetworkId and/or Network are added in the future, the changes in this PR will: - [x] Continue to work without code changes, OR trigger a compilation error (guaranteeing we find it when a new network is added)
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.
Description
The
react-native-fsproject is no longer maintained, and I don't have faith that a new version with the changes we need will be published. It seems like the maintainer of the project has changed but he is now publishing a fork rather than publishing from this project (contexthttps://github.com/itinance/react-native-fs/issues/1197). The fork has a lot of changes and it seems that most projects have not yet migrated to this fork (low downloads on npm). I don't want to make a decision now about which lib to migrate to and introduce more changes than necessary given the deadline for these privacy manifest changes. So this PR contains a patch that I made for the lib, and I used the same declared values as in the fork (I did also verify that the values seem reasonable).Test plan
n/a
Related issues
Backwards compatibility
Y
Network scalability
If a new NetworkId and/or Network are added in the future, the changes in this PR will: