- Node.js Web Development
- David Herron
- 417字
- 2021-06-11 18:48:17
Choosing Node.js versions to use and the version policy
We just threw around so many different Node.js version numbers in the previous section that you may have become confused about which version to use. This book is targeted at Node.js version 14.x and it's expected that everything we'll cover is compatible with Node.js 10.x and any subsequent release.
Starting with Node.js 4.x, the Node.js team has followed a dual-track approach. The even-numbered releases (4.x, 6.x, 8.x, and so on) are what they're calling long term support (LTS), while the odd-numbered releases (5.x, 7.x, 9.x, and so on) are where current new feature development occurs. While the development branch is kept stable, the LTS releases are positioned as being for production use and will receive updates for several years.
At the time of writing, Node.js 12.x is the current LTS release; Node.js 14.x has been released and will eventually become the LTS release.
A major impact of each new Node.js release, beyond the usual performance improvements and bug fixes, is the bringing in of the latest V8 JavaScript engine release. In turn, this means bringing in more of the ES2015/2016/2017 features as the V8 team implements them. In Node.js 8.x, the async/await functions arrived and in Node.js 10.x, support for the standard ES6 module format has arrived. In Node.js 14.x that module format will be completely supported.
A practical consideration is whether a new Node.js release will break your code. New language features are always being added as V8 catches up with ECMAScript and the Node.js team sometimes makes groundbreaking changes to the Node.js API. If you've tested on one Node.js version, will it work on an earlier version? Will a Node.js change break some assumptions we made?
What npm does is ensure that our packages execute on the correct Node.js version. This means that we can specify the compatible Node.js versions for a package in the package.json file (which we'll explore in Chapter 3, Exploring Node.js Modules).
We can add an entry to package.json as follows:
engines: { "node": ">=8.x" }
This means exactly what it implies—that the given package is compatible with Node.js version 8.x or later.
Of course, your development environment(s) could have several Node.js versions installed. You'll need the version your software is declared to support, plus any later versions you wish to evaluate.
We have just learned how the Node.js community manages releases and version numbers. Our next step is to discuss which editor to use.
- 深入核心的敏捷開發:ThoughtWorks五大關鍵實踐
- Spring 5.0 By Example
- 潮流:UI設計必修課
- Magento 2 Theme Design(Second Edition)
- Java 9 Programming Blueprints
- C語言程序設計案例式教程
- Scala編程實戰(原書第2版)
- BIM概論及Revit精講
- Visual C++開發入行真功夫
- 軟件品質之完美管理:實戰經典
- Learning Splunk Web Framework
- Java 從入門到項目實踐(超值版)
- 面向對象程序設計及C++(第3版)
- MongoDB Cookbook
- Ionic3與CodePush初探:支持跨平臺與熱更新的App開發技術