>>> The Future of `react-native-fs` <<<

[birdofpreyru]

Hello folks!

As the sorry state of this library started to compromise my projects, I decided to take it into my own hands, to give it the maintenance it well deserves, as a library providing essential functionality for many apps. I got no reply yet from the current owner in #1115, thus at least for the time being my fork of the library will live at https://github.com/birdofpreyru/react-native-fs, and it will be published to NPM under the name @dr.pogodin/react-native-fs.

As of my first release, v2.21.0-alpha.1, I've already refactored the code base to follow create-react-native-library setup, made it compatible to the new RN architecture, while backward compatible to the old RN architecture, with support of Android, iOS, macOS (Catalyst), and Windows platforms. The catch is, so far I only tested the exports of path constants, and a handful of selected functions, which I need for my current projects depending on this library. The rest of stuff may or may not work — the code is there, and it does not break the library builds, but I am pretty sure some functions definitely need some adjustments of signatures on native side to be correctly linked to their counterparts in the TypeScript layer (i.e. there they should be carefully tested one-by-one, and their behavior should be checked against the documentation as well), and then there are definitely some more fixes, optimizations, API & documentation improvements to do.

Thus, if you want this stuff to happen rather sooner than later, and more focus on the aspects important for your projects, please consider sponsoring my work on this library (there is a GitHub Sponsor button in my fork, and alternative forms of payment sure can be arranged), for I am a freelancer, not backed by anybody in particular, and as much as I'd love to contribute solely for the good of the community, earning for the butter on my bread is my top priority — without sponsors my work here will be guided mostly by my particular needs from this lib. PRs are sure accepted as well, if you just want to make a quick patch somewhere you need :)

Cheers! 🍺🤠

[xiaobaicai111]

From react-native-static-server to here, but thank your efforts🍺

[itinance]

Hi @birdofpreyru, thank you very much for your initiative. As I already wrote here one year ago (#1115), I can not provide all the time anymore that is required for being a maintainer of such a big library that consists of multiple archs like iOS, Android and Windows (which is the most problematic part for me since I even don't have touched any windows-device since more a decade). Moreover, I left the RN space some yrs ago, so I am constantly asking for a successor for my RN libs but could not find any candidate so far who was willing to take over.

If the community wants me to transfer this library over to someone, I would do that. Let's see if we can somehow find any consensus here to make that happen or if your fork will be the go-to-lib for FS from now on.
I would be happy with everything that would lead to a successful operational mode for rn-fs.

Chears, hagen (@itinance)

[qwertynik]

@birdofpreyru successfully revived the react-native-static-server package. Certain that this package will also be well maintained by him.

[GNUGradyn]

Any update on this? I'd love to see the official repo be compatible with the new RN architecture.

[birdofpreyru]

On my side, as of the latest release of my fork, v2.21.0-alpha.8, I'd say I got covered both new and old architectures for RN 0.72 on all platforms (Android, iOS, macOS, Windows) for the most important functions (find the exact list in the release notes at the previous link), which I need for my projects, and which were needed by a few of my past sponsors for their projects. There were also a few minor patches of the existing functionality, and a few new functions added. I got no financial support so far for working on this library, thus I don't have much motivation at the moment to finalize the support of remaining functions, nor to do a further development, as I am busy with other projects that pay or potentially will pay for the butter on my bread. That said, once RN 0.73 (and subsequent versions) is out, I'll be updating my fork anyway, as that I'll surely need for my projects.

@GNUGradyn

[RonRadtke]

@birdofpreyru i have a lot of the functionality in my lib https://www.npmjs.com/package/react-native-blob-util
Including mediastorage APIs and so on...
Therefor my suggestion to not work on both but join forces and work on one lib for file access + download since both must of the times goes hand in hand.
What do you think about that?

[birdofpreyru]

@RonRadtke To me it makes more sense to have two separate libraries, one for file-system operations, another for downloads, uploads, and other networking operations; and where networking requires to operate the local file-system, it should just rely on the first library. I have no idea, how RNFS ended up with downloads & uploads functionality, and why RN-blob-util re-creates some file-system functionality, while its primary focus seems to be the networking. Having them split and re-arranged, it would be a way more manageable to maintain and develop each of them separately.

Then, on the other hand, separate or combined, doing anything requires quite an effort, which nobody wants to fund. And without funding, I don't have much motivation to spend much of my time on react-native-fs (my fork of it) — in its current state it is already up-to-date with the latest RN, covering everything I need from it, and even downloads & uploads pieces which I don't need, so right now it is not clear why to invest more time into it, beside eventual updates to new RN versions. Not sure, what do you have in mind?

[RonRadtke]

That's a good question, which likely only can be answered by the original developers from 8 years ago.

But probably as everything, small features were added and then extended till both libs had quite a bit of everything. Like for my lib, it just makes sens that you can specify a path where the file should be downloaded to. Same later on with mediastorage. And since there was no other lib available offering it, I of course added it to the one I could andthat had a lot of file operations already.

But seperating it now would be like writing the whole lib new. So that's not an option.

My plan is for my lib to keep it up to date with new APIs and everything. And also to add new features. But also to do a rework of the whole API offered by the lib.

So the reason for asking is, we will mostly implement everything twice because both libs kind of do the same just a little different. Splitting also would mean that one lib can't really be used without the other - at least for the download part.
And even though structure wise 2 libs are better that would be quite a lot of work to realise this.
And same as we are currently doing it with a markdown lib, developing twice is a waste of resources and therefor should, if possible and wanted, be avoided