Chore: drop minimum node 14 version to 14.16.1

[ErisDS]

refs: #14592 (comment)

• this will allow the Ghost project to update their version of ESLint without impacting on all of our users

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[x] Other, please explain:

What changes did you make? (Give an overview)

I've changed the minimum version of Node 14 that ESLint supports from 14.17.0 back one version to 14.16.1.

The underlying reason for this is that in #14592 the change that intended to drop support for Node 10, 13 & 15 also set the minimum version of Node 14 that ESLint supports to 14.17.0.

For most projects this shouldn't be a problem, of course everyone should be on the latest and greatest Node!.

However, for Ghost - which is an application, not a library - we will have to change our own node engines from 14.16.1 to 14.17.0 in order to install the latest ESLint. ESLint is a dev dependency that we use when building Ghost, it is not relevant to our end-users.

But if we change our node engines, then all the end users who run Ghost will have to upgrade their Node version in order to get the next version of Ghost.

It doesn't make sense for us to force this just to get a new version of a dev dependency that has no impact on a production install or an end user.

By pure chance, we're just 1 Node 14 version behind the version you have pinned - we're pinned to 14.16.1 rather than 14.17.0 and therefore I was hoping you would be willing to accept this minor low impact change in order to help us out.

Is there anything you'd like reviewers to focus on?

I understand this is an odd request and very specific to one project, however:

• This would be extremely helpful for us
• I think this is an unintended side effect of the change to drop 10/13/15
• This change doesn't affect the intention of the original change

I do not believe there is a specific reason for the choice of 14.17.0, but if I'm wrong no worries.

Thanks for reviewing this PR & considering this change🙏

[linux-foundation-easycla]

The committers are authorized under a signed CLA.

• ✅ Hannah Wolfe (b8337fe)

[nzakas]

The reason we chose 14.17.0 is because that's the version where ESM was marked as stable in the 14.x branch. (#14023 (comment)), and we need to be able to use ESM going forward.

Some questions:

1. Do you have a bump to 14.17.0 already in the works, and if so, what is your timeline on that? (It may be feasible to just stay on ESLint v7.x until then?)
2. Are you aware of any ESM differences between Node.js 14.16.1 and 14.17.0? If they literally just flipped the "stable" switch, we could consider making such a change, though that wouldn't be my preference.

[bmish]

Dropping ESLint's required Node version below the version that officially supports ESM (14.17.0) is a pretty big downside for ESLint, so I'm strongly against that. It's better for us to be more strict/safe about the versions we support. It's also generally easy for consumers to perform minor Node version upgrades (e.g. 14.16.1 to 14.17.0) to solve the problem.

However, for Ghost - which is an application, not a library - we will have to change our own node engines from 14.16.1 to 14.17.0 in order to install the latest ESLint. ESLint is a dev dependency that we use when building Ghost, it is not relevant to our end-users.

I've run into this situation myself many times--it's a common situation with dependencies, but it's not specific to ESLint. The easiest solution is to just wait until you bump your project's Node version requirement in a future major release, assuming the upgrade isn't urgent. If you're using yarn, you could also try something like yarn install --ignore-engines when installing dependencies / running linting internally.

[ErisDS]

Hoh-kay no worries! The commit message didn't give any reason for the version choices for 12 and 14 so I hoped it was just whatever was latest at the time & we would do no harm with this lil change 😉

We've already had a lot of churn on Node this year at Ghost for good reasons, and I didn't want to churn again for this one. Meanwhile, holding off on dependency updates === tech debt. Rolling out --ignore-engines across all of our development tools, CI and installers would not be a simple change... and would likely lead us into hot water.

If I can make a tiny suggestion, taking care to document the why instead of the what (which is already explained by the code) in commits makes it much easier for outsiders to follow what's going on in your code base 😬

Really appreciate all the time and care that went into responding to me here, thank you 🙏

[bmish]

@ErisDS totally with you on those points. I have some projects that still support older versions of Node and so they have a lot of dependencies (dev + non-dev) that I haven't been able to upgrade yet which is a pain. ESM is a big milestone so hopefully most projects will align their Node version/support with it in the near future. More about this: https://blog.sindresorhus.com/hello-modules-d1010b4e777b

[nzakas]

If I can make a tiny suggestion, taking care to document the why instead of the what (which is already explained by the code) in commits makes it much easier for outsiders to follow what's going on in your code base 😬

We generally keep the why in the issue and the what in the commit, with a reference to the issue in the commit message. Here’s the commit in question:

f3cb320