The issue was not finding the libraries code. The issue was the churn. So one day, you have a (in my case, small) set of libraries to get things going. Then 2 years after, compilation issues as they all have different requirements. So you have to find another common intersection between them and the node/react-native versions. I should have vendored some in the project.
In Android, libraries are much stabler. Deprecated functions are picked by the IDE and an alternative is often presented in the comments. I'd much prefer to have big libraries (as we have tree-shaking) especially when dealing with frameworks instead of the bazillion packages when trying to do anything with npm.
> So one day, you have a (in my case, small) set of libraries to get things going. Then 2 years after, compilation issues as they all have different requirements. So you have to find another common intersection between them and the node/react-native versions.
That's what the whole version control thing that I mentioned is good for. Check out a two-year old copy that resolves to a faithful reproduction of whatever it was you were able to use successfully when you first checked it in.
In Android, libraries are much stabler. Deprecated functions are picked by the IDE and an alternative is often presented in the comments. I'd much prefer to have big libraries (as we have tree-shaking) especially when dealing with frameworks instead of the bazillion packages when trying to do anything with npm.