> That and just how very fragile the entire JS eco-system is. Running NPM Update ranges from doing not much at all, to breaking my entire system making deleting all of node_modules the only realistic fix.
That just sounds like a poor understanding of dependency management.
Blindly running 'npm update' means just 'update all dependencies (respecting semver versions in package.json)'. You're going to have a bad time doing that, if you do it rarely, because a lot of stuff is going to update at once. The same applies in most ecosystems (maybe with exception of Elm that has strict enforcement of semver).
Sensible practice is to do something like 'npm outdated' (ideally in CI) to inform yourself of outdated packages and then manually update specific top-level dependencies judiciously, and re-run your test suite against them.
> That just sounds like a poor understanding of dependency management.
And yet a lot of tools and large packages will spit out an error telling the user to run NPM update. As someone who is new-ish to JS, I generally try and follow the recommendations of those who are supposed to know better.
> The same applies in most ecosystems (maybe with exception of Elm that has strict enforcement of semver).
I previously did C++. Breaking changes were few and far in-between. It helps when the library is only updated once every few years. :-D
Now days? Things that break in my environment:
1. Android Studio, I have never not had 2-3 hours of down time after an upgrade. Mostly involving...
The Android Emulator. After updates, it just doesn't start. This leads me to: The images on the Android Emulator. I finally have found one that works reliably, I am sticking with it.
Finally, Expo. It is just odd in places.
That is pretty much my entire development stack, short of my editor. Happily enough, VSCode updates just fine.
I have the RN debugger working more or less. There is a Cross Origin Resource error that occurs everytime RN opens up chrome, it opens chrome up to localhost, and I have to type in my IP address instead, which is a bit odd, but the debugger now attaches reliably, so compared to what it was like before, I'm good.
The Expo client is random. It tries to install Expo on the Android emulator all the bloody time, sometimes it works, sometimes it doesn't. I just want Expo to open. I have to use the client to open the emulator if my IP address changes, and this can take 10-15 minutes to jump back and forth between trying the command line client and the GUI client, eventually one of them opens my app.
And then if I login to my app too many times in the emulator, I max out the # of connections allowed to google's auth service and I have to shut down the emulator to close the connections or else I can't login again. I'm guessing it is a bug with how hot loading code works (not cleaning up open network connections?), but at least I understand the fix for it.
Basically the entire RN development stack seems like jank.
Also JS taking 5 minutes to compile blows my mind. I've compiled entire embedded OSes in less time than that (and they did more!).
never had problems with expo, the emulators dont hold state if you close them, only time it will reinstall is if you close and open the emu OR expo client has updated but you get a prompt asking to update
FWIW I regularly (every month-ish) update all my dependencies in my native iOS projects (cocoapods) and it’s exceedingly rare that things break and when they do, it’s a matter of tweaking <15 lines of application code to fix. Stuff really only gets ugly if you go upwards of a year without updates, and even then it’s still somewhat manageable.
So maybe some library ecosystems are worse than others.
I've had the same experience with the current enterprise Android project I've developed and maintained by myself (at a company). I have my library versions all in my top level gradle file and every few cycles I'll go through and update everything to latest and just build the app and see what happens. It's rare anything bad happens at all. I encounter far more trouble upgrading gradle and the build plugin itself than my dependencies.
That just sounds like a poor understanding of dependency management.
Blindly running 'npm update' means just 'update all dependencies (respecting semver versions in package.json)'. You're going to have a bad time doing that, if you do it rarely, because a lot of stuff is going to update at once. The same applies in most ecosystems (maybe with exception of Elm that has strict enforcement of semver).
Sensible practice is to do something like 'npm outdated' (ideally in CI) to inform yourself of outdated packages and then manually update specific top-level dependencies judiciously, and re-run your test suite against them.