Hexo: Supported Node version

[demurgos]

Hi,
I'd like to discuss which versions of Node should be supported by Hexo.
According to the current CI configuration, Hexo is currently tested against Node 6 and Node 8. As time passes, how should the supported versions evolve?
Are we targeting Node latest? stable? LTS? Other?

The main reason why I am interested in this is because I am currently inspecting the main hexo package and I feel that it would gain a lot from using async function. Since we don't use any transpiler, it requires Node 8 (stable) and would break Node 6 (currently LTS). The reason why I feel async functions would be an improvement for Hexo is that many functions mix a synchronous and asynchronous part, loosing the guarantees around exception management (try/catch block or .catch method). Marking these functions as async solves this issue and would also remove a lot of noise around Promise handling.

Beyond my concrete example, Node is always evolving: ES modules are starting to land, new ES versions are supported, etc. How fast should they be integrated in Hexo?
Among the hexo user, would requiring the stable version instead of LTS be a big obstacle? Since Hexo is used to generate static websites, I believe that the impact should be pretty small: you are not blocked by the Node version on some server you do not control. I believe that the audience of Hexo is able to get a stable version on their computer but I may be wrong. Is the trade-off worth it? I am interested in your feedback.

[JLHwung]

Hexo is currently tested against Node 6 and Node 8

Hexo is tested against 6, 8, 9 on travis. Will add 9 to appveyor later (I am bothered that they do not use nvm)

Are we targeting Node latest? stable? LTS? Other?

Personally I prefer to target at latest and LTS. From the issues page we are almost assured most active users use node 8 or later on hexo.

it would gain a lot from using async function

I prefer to

1. use lebab to ES6ify the whole codebase.
2. use prettier to format the whole codebase.
3. use lint-staged + git-exec-and-restage to enable incremental formatting on later contribution
4. extend airbnb/best-practice and es6 settings in eslint-config-hexo

It is tedious to fix the code style error or any ES6 eslint rule. We'd like any junior programmer to contribute high quality codes via code quality tools.

ES modules are starting to land

After using lebab to ES6ify the whole codebase, we can use @std/esm to change all commonjs require to ES import.

[demurgos]

Hi,
Thanks for your reply.

A good starting step for this kind of migration would be to add an engines.node field in your package.json so older versions already get a warning.

I am not very aware of linting tools for Javascript. My main language is Typescript that already solves many common issues, and I use tslint for code style. npm test runs tslint as part of the tests. One of the best features of tslint is the --fix option that solves most of issues. I don't know if you're interested in incrementally migrating to Typescript to use types as documentation and static checks but I could help if you're interested (starting with smaller plugins for example). This reduces the risks that junior (or senior) programmers introduce bugs but may increase the barrier to entry.

[demurgos]

Closing this issue since the main question was answered:

Hexo's policy is to target the latest and maintained LTS versions of Node. It means that it is acceptable to use new features as long as they work on the maintained LTS versions.

For reference: nodejs/Releases