fix(node): remove node 6 and 8 support

[jimthedev]

This removes node 6 and 8 support. This is a free project and our builds are getting very long so we
have to be a bit careful about what versions we test on. To be clear, this still works on Node 6 and
8 for now but we won't be maintaining that guarentee into the future so please work towards
updating. Additionally it removes eslint in an attempt to minimize dependencies. If we add anything back in it would likely be prettier.

BREAKING CHANGE: Removal of two major node versions, 6 and 8 from testing scheme

[commitizen-bot]

🎉 This PR is included in version 4.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[KengoTODA]

Hello @jimthedev, does this change means that not only cz-cli but also the whole semantic-release series stop supporting Node 8?
If so I will propose this change to semantic-release repository. Thanks in advance :)

[EECOLOR]

I think it's not great to remove support for node 8 while it is LTS: https://github.com/nodejs/Release

It would be nice if the whole ecosystem would follow that schedule.

I also wonder how it relates to: conventional-changelog/conventional-changelog#436

[KengoTODA]

Sorry I found that I mixed semantic-release and commitizen. Plz ignore my comment.

[StephanBijzitter]

To be clear, this still works on Node 6 and 8 for now but we won't be maintaining that guarentee into the future so please work towards updating.

This is not quite true:

error commitizen@4.0.1: The engine "node" is incompatible with this module. Expected version ">= 10". Got "8.10.0"

Yes, the code would still work, but by default you can no longer install commitizen, so yeah.

Anyway, not complaining here, makes sense that you changed the NodeJS version requirement.

[jimthedev]

@StephanBijzitter is right. You can use --ignore-engines in yarn to get around this requirement I believe.

[StephanBijzitter]

Yes, but that essentially just hides the message and we may forget that our NodeJS version is not supported anymore, get weird behaviour at one point and then we're going to wonder why it's not working :-D

Plus, sadly that ignores engine checks for all dependencies, so we may also miss out on other dependencies dropping support in the future.

There's not really a perfect solution here, it's just how it is 🤷‍♂.

For anyone interested on why we're stuck with NodeJS 8.10.0:
alixaxel/chrome-aws-lambda#37

[jimthedev]

That’s fair. I can add 8 back in if needed. Just trying to keep things moving towards LTS current.

[StephanBijzitter]

Oh no need, someone else may come along and have a good use-case to still use NodeJS 6, 4, 0.12... it'd be a slippery slope. Dependabot will keep creating pull requests for every commitizen release and once there's a new feature important enough (or we've updated to NodeJS 10) we'll see a pull request pass all checks :-)

[jimthedev]

Perfect. Thanks for the feedback!

[EECOLOR]

@StephanBijzitter - Oh no need, someone else may come along and have a good use-case to still use NodeJS 6, 4, 0.12... it'd be a slippery slope.

I wouldn't say it's about use cases. It's about keeping in line with LTS versions and 8 has LTS until the end of the year. If there is any library that does not support an LTS version you have a good argument for them to update.

@jimthedev - I can add 8 back in if needed. Just trying to keep things moving towards LTS current.

If it's not a big deal it would be great to add it as long as it has LTS. You can schedule removal of support by looking at the release table.

It would be great if the node js library community would move in tandem with the target of their library (node js). As a community we already have kind of a bad reputation when it comes to backward compatibility.

Stating that we can just add --ignore-engines because it will still work will render the engines property unreliable. Other libraries might use it to indicate they dropped support and are incompatible.

[EECOLOR]

In my mind node js libraries should have tests for the following versions:

• LTS maintenance
• LTS active
• LTS current or latest

Where latest is just an indicator of incompatibility. With the last transition (when 11 was latest) all latest builds failed because a transitive dependency of my library (node-gyp) only supports long term LTS releases. The latest check provides a window in which libraries can update their code to the latest version.

Consumers of libraries should only switch to the new LTS when it becomes active.

[travi]

keeping in line with LTS sounds great, but if its more maintenance than its worth, i would much rather see support further limited for all the reasons outlined in this article. LTS is defined for node itself. it is unrealistic pressure to put on maintainers of all kinds of packages.

if your version of node isn't supported by the new version, don't upgrade. if you want to be on the latest version of this package, take the steps to move to a supported node version. the maintainers of this package don't owe you the extra effort so that you can have both.