Unfortunately, we have projects with different nodejs versions. I am not sure if this is like java where I can have multiple jdks installed(multiple nodejs installed) and each project magically uses the correct version via a config file? Also, most commands in tutorials are not including version numbers when installing tools and libraries like so

• npm install -g expo-cli (tool)
• npm install @react-navigation/native (library)

Coming from gradle with the gradle wrapper where everyone on the team uses the tools and library versions defined in the build.gradle file, this is odd to me. In the gradle world, everyone on the team uses the same exact version of gradle(gradle itself ensures if one person upgrades it in the repo, everyone gets the upgrade and stays in sync on the same version). Then there is plugins/tools and those versions are defined and then libraries and those versions are defined.

• How do I guarantee everyone is using the same npm, node, expo, etc. tools?
• How do I guarantee everyone is using the same libraries?
• How do I guarantee everyone is using the same typescript?

Ideally, we upgrade any of these in the repo any fixes to the upgrade so on checkout, developers start using the new tool new *.tsx files so it is seamless much like in the gradle world. In gradle, I upgrade the

• version via a property
• versions of plugins/tools
• build.gradle files
• any source code files

and check that all in as a unit such that any developer that checks out is using all the correct versions together. I want this in react-native for our ios/android mobile project or as close as I can get.

I have hacked things before as in installing 'ant' into the git repo and this worked wonders(even though it is such an ugly hack) and everyone used the tool in the repo instead of the one on their OS. Perhaps there is a way to do that?

A bloated repo with binaries was worth it's weight in gold to prevent version compatibility hell as people upgraded libraries over time. NOT only that we found that tool bugs were easier to track down as we could revert the repo. NOT only that, we could reproduce builds form 1 year ago as the tooling was reverted where todays npm tools can't build the 1 year ago thing due to all the changes. The advantages just kept piling up and up and I can't even remember all of them.

Tooling running from the repo either via bootstrap like gradle wrapper or full blown thing is generally the best option until the full blown thing is really bloated but even then locking it to a hash on another tool repo could be better

Any ideas welcome here to put my team on all the same tooling(works great for people joining the company or team from another project as well to not have to install much).

thanks, Dean

CodePudding user response：

Typescript and libraries should be taken care of by removing any carets and tildes in your package.json and specifying exact versions.

One low overhead possibility for the rest could be shell scripting and a private package repo. You could host the versions you want to install internally, and get it all through cURLs.

Or you could add some simple scripts in your npm pre-install, for example nvm use 12.2.1 should, through error messages, guide the user to installing nvm and using the proper version.