3 ms·
Actually, since the RN team unbundled RN and handed maintenance of non-core libraries (e.g. filesystem, keychain, gestures...) to community maintainers, a lot o
by meego 4y ago
Actually, since the RN team unbundled RN and handed maintenance of non-core libraries (e.g. filesystem, keychain, gestures...) to community maintainers, a lot of these libraries have lacked maintenance, and could really use more maintainer time.
The following example comes to mind. react-native-fs is the most popular lib for filesystem I/O. From Android 10's release in Sep 2019 until Feb 2022, all file overwrite operations on Android 10 and later would result in the file getting corrupted if the new file was smaller than the pre-existing one. Related issue: https://github.com/itinance/react-native-fs/pull/890 https://github.com/itinance/react-native-fs/pull/890
That's a very long 2 year and a half.
My intuition to explain this situation is that the intersection of these two is very small:
- orgs using RN, and thus willing to maintain it
- orgs staffed with experienced Java/Kotlin or ObjC/Swift developers with the good understanding of native Android/iOS APIs needed to maintain RN libraries