Node engine version requirement
See original GitHub issueCan someone tell me what’s the lowest version of the node engine ver requirement? When I look at the http://node.green it looks like the 6.11.0 might be enough. But 7.10.0 looks more promising (because of async/await features). So there are any suggestion?
Btw maybe it’s time to add in package.json:
"engines": {
"node": ">=min_ver_req"
}
Issue Analytics
- State:
- Created 6 years ago
- Reactions:1
- Comments:8 (2 by maintainers)
Top Results From Across the Web
How can I specify the required Node.js version in package.json?
You can set the engines field in your package.json and set requirements for either node or npm versions or both: "engines" : {...
Read more >How to define the required Node.js version in package.json?
To define the required Node.js version in the package.json file we will have to go through few simple steps:.
Read more >How to check minimum required Node.Js version - Medium
For many apps may be useful to check the Node.Js engine version and require specific version. We can use “engines” section in package.json...
Read more >Node Engines: Helping Developers Everywhere Avoid ...
Specific Node.js Engines Should Be a Required Field for Every Package. ... Similarly, our React application needs Node version 10 or higher, ...
Read more >Node.js Runtime Environment - App Engine - Google Cloud
The Node.js runtime supports Node.js 18 (preview), Node.js 16, Node.js 14, Node.js 12, and Node.js 10. The runtime uses the latest stable release...
Read more >Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
4.x is a nightmare.
By the time something is actually done on this side, it’s going to be in maintenance. By the time it may matter, it’s going to be E.O.L.
On the consumer side, upgrading from Node 4 to Node 6 is trivial. It’s supported in every PaaS that has lambdas & you are gaining features not dropping them.
The simple truth is Node v4 was their digging out of a hole release & for what they had to accomplish, they did a commendable job but Node as an org has moved on. People should have been off of Node 4 already or at least have it planned, enabling the slow adoption rate while hamstringing a project is a mistake.
Simple enough solution. Don’t set the engines until v8.0 hits LTS & then set the precedent that both LTS versions are supported & the project moves with the LTS schedule.
From the perspective of a maintainer ( we are just now getting away from 4.x in Webpack ) it’s been a constant source of aggravation as well as being extremely limiting during development.
Personally, given this is relatively new and there are no existing support requirements it would probably be beneficial to set it and 8 ( the soon to be LTS ).
Dropping older node versions is always cumbersome for maintainers ( we still have to support 4.3 in Webpack ). I would personally push the minimum out as far as possible and start as far ahead of the game as possible. Once it’s set you are going to be tied to that minimum for quite a while.
Also, while I understand you point about async/await. It’s unwise to set a min support version to a node development version as amongst other things, it doesn’t get updated once the even number release drops.