build-image
build-image copied to clipboard
Attempt to use 'Engines' section of package.json to set node version
Not sure if this makes sense since the field can contain a range of versions rather than specifying an exact version, but maybe we could limit it to supporting only a definition for node that is a single version #?
This would be in addition to setting NODE_VERSION or .nvmrc since we obviously can't deprecate the existing methods without breaking a lot of builds.
what do you think @rybit ?
I think that there are extensive docs on the things engine could be used for - including yarn and npm version setting:
https://docs.npmjs.com/files/package.json#engines
I am unfamiliar with that section of the package.json, but you're saying we could parse out a specific node version and try to set it via nvm?
If this is the 'standard' (as much as anything in JS is standardized) then yes, but personally, I don't see this as being a great way. We'd have to use jq
which isn't bad, but the range vs exact could be more confusing to end uses.
Not against it though.
Hi, I do believe engines
in package.json
is a kind of standard. In any case, it would be nice to avoid the extra nvm file if there's already a package.json.
https://yarnpkg.com/lang/en/docs/package-json/#toc-engines https://docs.npmjs.com/files/package.json#engines https://zeit.co/now#which-version-of-node.js-do-you-run
Hi! Just wanted to add that Heroku also uses the engines
config in package.json
to determine the node, npm & yarn versions. When ranges are used, I believe they simply use the best match. If nothing's provided, they use the latest LTS release:
https://devcenter.heroku.com/articles/nodejs-support
This tripped me up a bit when shifting my project from Heroku to Netlify. For now, I've created a netlify.toml
file which duplicates my engines
config, but it would be great to support this standard.
I would like to see this happen too.
Having this in package.json
would help keep multiple tools / services in sync.
Please have Netlify pay attention to package.json's engines
object.
We should be able to:
{
"private": true,
"engines": {
"node": "14.4.0",
"yarn": "1.22.4"
}
}
and it just work.
Even after prefixing my build
script with NODE_VERSION=14.4.0 YARN_VERSION=1.22.4
I get version errors on Netlify. Do you guys just support a few versions of Node/yarn???
Versions (specifically Node/npm/yarn) has been a goofy problem since Netlify was created and has probably cost you guys a ton of money in failed deploys. Please actually fix this once and for all with a simple solution (e.g. NODE_VERSION=14.4.0 react-scripts build
actually works, and/or Netlify draws versions from the engines
field (the more correct solution)).
Posterity: Netlify doesn't pull env vars out of commands. So NODE_VERSION=14.4.0 react-scripts build
won't work. And they don't look at engines
(they should). You need to add Node/yarn/npm versions here:
As far as I know, our builds should support every released version of node and yarn. It is the specific inclusion of the engines
line that may be problematic, or at best won't work.
If you'd like to link us to a failed deploy logs page once you've set $NODE_VERSION
and $YARN_VERSION
and removed the engines
settings frompackage.json - probably best done by a post in our community rather than in this thread - our Support team will be happy to try to debug there.
This feature request is about supporting that line and is still good to follow for your use case, but I think we can come up with a workaround today - just not at the expense of everyone following this thread having to read our back and forth ;)
No worries. This is where I ended up from googling something like netlify engines
so I figured I'd drop a screenshot for others.
just set the NODE_VERSION: Sets the Node.js version. on env variables https://docs.netlify.com/configure-builds/environment-variables/#deploy-request-notifications
Any updates on respecting engines.node
?
Pinging here again to see if this is moving to package.json
.
I found this issue from this support forum: https://community.netlify.com/t/specifying-a-node-version/9701
thanks for the ping @micleners ! Any updates to this functionality will be posted in this thread :) None are planned today as far as I know. The workarounds listed here continue to be our best advice for today.
I had to spend a few hours understanding why my builds fail. Then later I saw, I had to set env variables for the node.js version. Although it is the only workaround currently available, it sure goes out of sync when we update "engines" in package.json and forget to update env in netlify.
EDIT: This is my first post, and I forgot to say thanks for providing such a good tool free for open source projects.
Like this?
I get this:
Is there any movement on this feature request? engines
is absolutely the standard way to define what node versions your project can be built with, so I'm not sure why we would want to manage it separately in Netlify. Not everyone uses NVM (some of us manage our node versions with volta
, for example), so there won't always be a .nvm
file to read the version from, but there will always be package.json
, which already has the engines
spec. It's really unexpected for Netlify to not know what version of Node to build with, when we've specified it in our project already.
Yeah it would be really good if Netlify would just respect the semver Node version in the package.json engines definition instead of having to specify the version in two different places.
I don't see the fact that this version can be a range as a problem. You can simply apply the same version resolution algorithm as npm/yarn apply.
Meaning, if I specify Node version as "16.3.0" it will give me 16.3.0. If I specify it as "^16.3.0" it will give me whatever 16.x.x is available and the latest, but not 17, 18 etc.
I'm surprised that some are asking if this is standard.
Anyway, yes it is.
edit. just realized that the .node-version
file doesn't support semver, come on guys.
Can we please please please get this implemented?! It's so trivial and yet this issue has been open 4 years! This aspect of explicitly setting node versioning for Netlify still trips me up on new projects and it's becoming a nuisance at this point. Why is Netlify being so stubborn about this?
So, somebody at Netlify didn't know about engines
however many years ago so now all your customers are stuck with failing builds and workarounds? I don't get it, especially with the momentum toward TypeScript where your @types/node version is in package.json
.
Adding my support for this. I use this on Heroku and I don't use nvm at all because I don't need to manage multiple node versions on my laptop. All my projects are built with the latest versions. Netlify has been building my sites with the wrong npm and node versions (6.x and 12.x instead of 7.x and 16.x, respectively) and I only just now noticed.
This seems like a really obvious thing to support since it's part of the package.json standard. Seems wild it's been 5 years since it was requested without any movement.
bumping this, it's pretty ridiculous that this has not been implemented yet.
Once again sending this to the top. Got here after struggling to get the node version updated in an older project that got resurrected and spend a while figuring out why Netlify was failing to build. Is it still expected that we updated the node version via the environment var in the Netlify UI when needing to do so?
Ah, the old spending 4 hours in Netlify build hell because of some weird unsupported thing again. Oof. Can anyone from Netlify take ownership of this problem? @erezrokah?
5 year old issue!
I just ran into an issue where my builds were failing because I guess webpack requires something newer than Node 12, but that's what netlify was trying to build with despite my engines
section specifying it should use Node ^17.0.0. This really needs to be addressed.
Since there hasn't been any movement on this I went hunting to see how Heroku and others do it. Heroku is using a custom binary that checks their installable inventory on an S3 bucket and figures out what version matches the specified range, so that was kind of a non-starter, but there are other ways to get at this info.
npm view node@^17.0.0 version | tail -n 1 | cut -d "'" -f2
This will output the latest matching version of a package. In this case it's the latest version of node matching ^17.0.0
. It should work with any semver range you give it since npm handles that stuff. I tested with a bunch of them, including some unsafe ones like <17.0.0
and >17.0.0
. And, of course, it works with exact versions, too.
This solution isn't necessarily my favorite because it could require installing two versions of node/npm and only works with packages that are actually available from npm, but it does work and removes any custom range parsing/logic concerns from your plate. Since most folks seem to be asking about node/npm/yarn, and those are all available on npm, it probably isn't the worst thing in the world to only support stuff available on npm.
In install_dependencies()
after you've copied over the cached node version you could add a third if
after the one that checks .node-version
where you use jq
to parse out the preferred version from engines
, run it through the above check to get the best matching version, and then install that. It looks like you're already restoring a cached version of node and then using nvm
to install the desired version.
If I'm reading this script correctly (totally possible I'm misunderstanding the use of the cache) then it almost seems like you're most of the way to having this particular, if less than ideal, solution working already without adding any extra lift for stuff like version range parsing. Maybe I'm wrong!
And looks like, that without this implemented, I cannot deploy a new project after an update to Netlify. This should be addressed ASAP. Everyday people have more and more reason to upgrade to newer version of node.
that's not true, @noisy . You can use any node version you want; you need to set a node version in our way, which is use $NODE_VERSION
and put whatever version you want in it, in the way we have documented here: https://docs.netlify.com/configure-builds/environment-variables/#netlify-configuration-variables
@fool I mean, as demonstrated by that comment from @noisy, the fact that folks know about engines
but not the Netlify-specific way to do this, and the fact that people even believe the only way to do this is engines
should lend some credence to the idea that engines
is the right way to do it and should be supported. 🤷🏻♂️ Just my take.
I too, would appreciate it if support for engines
is added, as it's extra work and easy to forget to update the Node version in Netlify config.