5 ms·
I have been working on a commercial RN project for 2 years now. As of today, the project is ~50kloc, and provides builds for Android, IOS, Windows, and Macos pl
by invaliduser 8y ago
I have been working on a commercial RN project for 2 years now. As of today, the project is ~50kloc, and provides builds for Android, IOS, Windows, and Macos platforms. I started it using RN after prototyping with an early Ionic2 version and checking Xamarin.
The code share between IOS and Android is very high, almost 100% (except a few simple home-made native components), and we are above the 85% of shared code between the mobile and desktop versions (mobile is RN, desktop is react-native-web + rewriting of several components on a Qt WebEngine with native versions of a few RN components rewritten in C++). The C++ part is actually very simple, and under 2Kloc. Note that we use Typescript everywhere on the React side, and we consider it very valuable.
Overall, everything works great, we have a few performance issues here and there, but nothing we can't deal with. However the biggest flaw is how indigent the build system is (combining all the flaws of npm and the issues of android upgrades), we still do not manage to have reproducible builds, and it's been sometimes very painful to fix an issue a few weeks later because it would just not build and require a few hours to make it build again.
- mwilliaams 8y ago> all the flaws of npm Can you not use yarn?
- spinningarrow 8y agoWhat flaws of npm does yarn fix?
- Humphrey 8y agoOh my where do I begin -- Yarn (to me) appears to be faster, and breaks less (if ever). With NPM I kept finding things not working, and having to delete node_modules and re-installing. Yarn just works, and I haven't even considered using NPM since installing yarn.
- passivepinetree 8y agoDo you have any actual issues yarn solves for you besides an anecdotal “it just works”?
- Klathmon 8y agoI do. It caches locally and doesn't hit the net for most redownloads, the lockfiles are significantly more reliable, there's the ability to "force" a transitive dependency to another version, the workspaces system lets you work with monorepos with multiple packages much easier, tools like "upgrade-interactive" are built in and make upgrades much easier, and more that i'm probably missing.
- sli 8y agoEhh, I have a `yarn depreset` command in my package.json files on most projects at work because I still often have to delete node_modules and reinstall everything. I got tired of typing out the whole thing. Granted this is oftentimes because our dependencies float a bit, especially since we've been migrating to a new major version of one of our major dependencies, but it's still usually the quickest way to fix weird dependency issues. For us, npm tends to be really wonky in a CI environment. Partially because our CI container needs updating, but also because `npm install` doesn't actually do what you think it does. Gotta use `npm ci`. But the npm in our CI container is old enough that it doesn't actually support that command (yeah yeah, I know -- I don't have access to that part of our build process). As of npm 6 though, the differences between yarn and npm have been whittled away considerably. Really, the biggest reason we use yarn is because we also use React and a number of other libraries that come from Facebook, so we're just staying under the same umbrella. We don't expect Facebook to break their own tooling, basically, while npm has indeed broken a few things for us in the past, many times critical things. Not the most compelling of reasons to be sure, but that's why.