[cxr]

For any project that you depend on that has opted into the NPM quagmire, you really should be running `git add --force ./node_modules` and periodically pushing a copy of this to a branch/repo that you control instead of depending on upstream, since most projects that ostensibly use Git tend to thwart its entire raison d'etre—hobbling its ability to do effective version control by abusing .gitignore for their overlay VCS of choice (i.e. the "package manager").

[skydhash]

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.

[cxr]

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