My website is hosted on Netlfy for years and I use Ubuntu Xenial 16.04 to build my image. I have no idea why but it keeps installing Node 10.
Then recently I decided to update the build image to Ubuntu Focal 20.04. But after selecting the new image and start building, however the system still download Node 10 for building. Currently I set the Node version using NODE_VERSION Environment variables. But I would rather prefer not to touch the NODE_VERSION Environment variables and let the default version provided by the build image.
So I would like to know how can I force my project to use the default NODE_VERSION provided by the build image? Thanks in advance
Hi @coelmay I never set the NODE_VERSION value until recently.
Initially I updated my build image is Ubuntu 14.04 Trusty and I believe Node 10 is the default Node version, and this Node version just follows me forever - whenever I update the build image the system would still use Node 10 as I am still using Ubuntu 14.04 build image.
But as I mentioned I never set the value before and I used Trusty and then upgrade to Xenial and now Focal. But it keeps using Node 10 as default. Even I upgrade the build image.
May I ask another question, once the value NODE_VERSION is set, is it possible to remove the NODE_VERSION setting so the system would build based on the Node version in the build image? Thanks in advance.
Hi, @winstonma. This is done for the purpose of consistency. Each build image has a default version of various language runtimes (Node.js, Ruby, Python, etc.). If you don’t set a value manually, two things occur:
The default version is used.
That version becomes “pinned” behind the scenes.
This is done so that if you change the build image, the build behavior stays the same because the same versions are used for the site build.
I mentioned because, if we do removed this pinned version for you, the version will be automatically pinned again the next time you build the site.
Note, our support team can manually change the pinned version. If you would like us to do that, would you please let us know what site it should be done for?
The only workarounds without the support team making the manual change are to either pin it yourself with an environment variable or to delete the site and recreate it (which will reset the pinned version but it will be pinned to the new version again). If you delete and recreate the site you will lose the deploy history and other site settings so that is a far from ideal workaround but it doesn’t require waiting on the support team.
To summarize, these versions are always pinned behind the scenes and our support team can reset the pinning for you if the workarounds above are not acceptable (which are pinning yourself or recreating the site).
I really appreciate the reason but my reason for upgrading the build image is to use the ensure that my code works with new version of the build tool. So it is also beneficial for the developer to use the test the latest build tool (as long as the failed build doesn’t get deployed it would be fine).
It’s just my two cent, it is possible that the system run a test build with all new Environment variables of the build image. And fallback if it fail?
Hi, @winstonma. The workflow I would recommend to test an existing repository with a new build image would be to create a new site and link it to the same repo. That would be the most realistic test. You don’t loose your build history and you are guaranteed to get the default if you don’t manually set them in some way in your repo.
Again, the reason we don’t do that for an existing site is so that a working build doesn’t break when changing build images. Most people do not want to break their build when upgrading build images and that is why this behavior is the default. In other words, we default to what is preferred by the majority or largest group of people.
If you want to see if the new build image’s defaults will break the build, again, making a new site linked to the same repo is the guaranteed way to test that.
I also strongly recommend not relying on default versions in the build image. I believe most professional developers would recommend controlling your node version yourself and not relying on whatever our defaults are at Netlify. The node version should be whatever works best for your app and every app has different requirements. Netlify cannot pick a version that is best for everyone because there is no single version that is “best” for everyone.
With Node in particular, there are many ways to set the version used and there is more information about managing the build dependencies here:
Hi, @winstonma. I received the private message with the site name and updated the defaults to the Focal default. Note, you appear to have a manually set node version and these means my changes won’t have any effect.
Thanks a lot for your suggestion @luke. I would follow it. But still, after the testing the new build image I would like to rollout. Thanks for your suggestion too.
Also I removed the NODE_VERSION Environment variables and now it uses the default value. Thanks again