docs: add Node.js support policy

[nknapp]

Initiated by #1668 we had a discussion about support for Node.js versions. This is the write-up of result.

[bcoe]

Hey @nknapp @ErisDS, thought you might find this interesting reading (It's the version support goals I've been drafting for Node.js libraries at Google):

https://github.com/googleapis/google-cloud-node#supported-nodejs-versions

I'm working on a more thorough blog post I'll share pulling together my thoughts. It's motivated by this exact challenge I've been watching handlebars deal with this week.

Appreciate your hard work, and that open source can sometimes be incredibly frustrating 😆

Good thinking calling out your goals explicitly.

[mcollina]

I would kindly recommend against this. Dropping the minimum Node.js runtime is a breaking change.

[bcoe]

The opinion I've developed, as a library maintainer, is that 30 months is reasonable amount of time to support a Node.js version (which is the LTS length). It creates a burden for maintainers to support EOL Node.js versions:

• making it difficult to take patches from libraries in the dependency tree.
• opening you up to security vulnerabilities.
• making it so you can't take advantage of new runtime features.

At the same time, I do strongly agree that dropping a Node.js version should be a major bump. Otherwise I think you'll have the unintended effect that people start pinning to specific versions of handlebars.

I'm very sympathetic to handlebars' pain around dealing with the optimist vulnerability (it's frustrating to have work created for you, when you're already volunteering your time).

[nknapp]

@bcoe just wanted to say that I see your point and will think about it.

I will try to briefly make my point as well:

I belief that major version bumps should be never be done lightly, avoided if possible and carefully planned if necessary. 4.x now exists since 2015. Since then, we have mostly done bugfixes, added a few options and fixed security issues. But we haven't had any breaking changes in the documented API, so there was no need to release 5.0

Node.js drops support for an LTS version every year. If a security issue can only be resolved by upgrading a dependency to a new version and if that new version does not support the dropped Node.js version anymore, then we need to release a new major version of Handlebars, just because dropping support for the old version, even though we had no other breaking changes.

Also, only a very small part of Handlebars depends on the version of node.js (only the precompiler). Most of the code (compiler, runtime) is transpiled at the moment and does not depend on any node.js API.

So in the worst case, we have one major release every year with no other breaking changes. Maybe with only security fixes. This may well happen at our current speed of development and it really bothers me to have to do that.

On the other hand I can understand the benefits of your point of view. As I said, I am thinking about it, and maybe we should discuss this again.

[jaylinski]

@nknapp I think we should merge this into master (v5), but keep v4 Node.js support as is.

[akarsh]

Hello @nknapp

Good PR 👍

I agree with the PR changes as the workflow file https://github.com/handlebars-lang/handlebars.js/blob/master/.github/workflows/ci.yml#L20 mentions the minimum supported Node.js version is currently 18.x and Node.js projects depenending on GitHub Actions workflows are forced by GitHub Actions to updrade their projects to the supported Node.js version in https://github.com/actions/setup-node/

[nknapp]

It's been a long time since I opened this MR and I would like to revert my statement. It should be a breaking change.
The only reason to not run tests against all node versions it lacking support of the test-frameworks as far as I can remember.

I will close this PR now.

@jaylinski maybe a pragrmatic approach to dropping the currently old node versions is to discard that changes that have been done one the master branch and start clean off 4.x to get a 5.0, except for the technical changes like using the external parser repo maybe.

I don't know how much work you have put into the new version already, but all the features in there have been lying around for 8 years now without a release. I doubt that anybody really needs them.