I have also seen people post suggestions on how to use the library that are just flat out wrong. Suggesting using props that don't exist (!!!???), and I've seen at least three recommendations of how to do lazy loading. Now that the docs are better these issues are going to go away, but unfortunately old blog posts (and github threads) live on.

Speaking of the documentation, it has gotten 10x better over the last few months. It has a ways to go, and pictures would be super nice. The React Native community likes to post Expo apps to showcase APIs instead of having super robust examples in the docs, I get why (and sample apps can be super useful!), but sometimes a "this option results in this" doc is super useful.

When I was first learning the library, some of the documentations labeled navigationOptions, some of them didn't and just passed it in positionally. It looks like the docs have been cleaned up, hopefully other examples around the web do the same thing. When I was trying to learn the API, this was very confusing, but I think if I had to learn it from scratch today, it would be a lot easier.

(If Steven Girder hasn't updated his examples, ask him to! His RN course is insanely popular and introduces a lot of people to React-Navigation)

So I guess saying it is bad isn't correct, but up until very recently, doing anything with the library was an effort in frustration just because of the documentation.

I'm still going to DM you some questions about the drawer though! :) (Update: answered, I was doing some things wrong, and Drawer is being rewritten to make more sense!)

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.

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!).

I've honestly never encountered an error with a message telling me to blindly run npm update. What's a package that does this?

So maybe some library ecosystems are worse than others.

Could be time to switch from Gradle to Bazel. It would also be nice to see the last of Apache Groovy, don't you think?

Why not just pin your dependencies to specific versions, ie - “somepackage”: “4.2.9” ?

But I'm a crusty almost-30 .Net developer used to Nuget.

There really is no reason to be encountering surprise sub-dependency changes with npm.

No it doesn't. Since npm 5, npm is lockfile-by-default, you don't get updates unless you ask for them. Whether one particular package correctly respects semver is irrelevant.

Npm is more fragile than it should be.

Contrast this to how I've approached it in, say, Ruby...I'm very confident in blindly running `bundle update` and checking the diff to see the result.

I've been planning to switch to V2 in our starter kit for the next major release.

https://github.com/ueno-llc/react-native-starter