If you’ve read my last post, you know that
I’ve switched to using nodenv from nvm.
Why?
I don’t want to explain again, so you can read more about it.
The problem
Running the project with different versions of NodeJS may lead to unexpected results. This is especially true if we are talking about projects where more than 1 person is working on. But it holds true for personal projects that have been on the back-burner for some time.
Don’t forget this timeless quote:
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Source from StackOverflow.
Speaking from my personal experience, 99% of the time, the person knows where you live! Because this person is you! Yep, the person who wrote this “ugly piece of shit” was old me!
So… make sure you’ve done the best to your abilities to soothe the next person who’s gonna work on it. :)
The solution
If nvm is already adopted on your team - great! It’s a step in the right direction, also, good amount of CI providers have support for it (e.g. Bitrise).
Add an .nvmrc file with the following content: 10.16.3 (this is current LTS version, but probably won’t be by the time you read this).
Now, you want to have a .node-version file with the same content. But although copy/paste is the best tool in a developers toolbox, it’s not the right tool for our job.
You want to symlink .node-version to .nvmrc, in order to do so, execute the following command in the root directory of your repo:
ln -s .nvmrc .node-version
Now, if you execute ls -la then you should something like that:
❯ ls -l .node-version
lrwxr-xr-x 1 steliyan staff 6 Oct 5 19:02 .node-version -> .nvmrc
You’ve successfully symlinked .node-version to point to .nvmrc!
Conclusion
Don’t rely on the aliases that nvm supports!
Updating this file takes a minute! Testing those changes will take more time, but that’s to be expected! It may just mean to run all the integration tests locally or on your CI server. In the long term - this will save your time, and probably your ass!
The builds or environments are not reproducible. It may be OK for an evening project (but don’t forget about the psychopath who knows where you live!), but for production environment it’s absolutely not recommended! Something is going to fail when a trivial fix is being deployed. You can pray that to be the build, because more subtle errors may creep into production! However, having a broken build when you want to deploy a business-critical fix/feature is no fun.
Try answering this one question - would you produce a production build of your app without using a yarn.lock or a package.lock file? Yep, I thought so. :)
I’ve personally had a similar issue with this blog. I may write a follow-up post on that some day! ;)