chore: require node >=10

[varl]

Supersedes #299

We want to bump our required Node version to >=10 since some of the sub-packages (cli-style, cli-app-scripts, cli-utils-cypress) already use dependencies requiring those Node versions.

Dependabot also does not look closely at the engines field to determine compatibility so we need to make sure we are up-to-date ourselves.

BREAKING CHANGE: Require Node version 10 or later.

[amcgee]

Should we move to bundling Node and producing standalone executables soon?

[varl]

Yeah, but there's still the question about how to deal with the external sub dependencies like cli-utils-cypress, cli-style, et. al.

[amcgee]

Hmm but I think those would be bundled as well?

[varl]

Hmm but I think those would be bundled as well?

Yes, ultimately. What I mean is that all of our external sub-packages can define different versions of Node, so we would still have to keep track of when an external sub-package breaks compatibility, we need to bump the Node version in CLI as well.

[amcgee]

I think this is fine to merge, will do a quick test. @varl just curious, why is the fs-extra upgrade tagged as a breaking change though?

[varl]

That's a fair question. Bumping fs-extra from 8 to 9 is why I started looking into bumping node to >=10, as they list that as a breaking change in their changelog as well: https://github.com/jprichardson/node-fs-extra/blob/master/CHANGELOG.md#900--2020-03-19

The question is how should we handle when deps cause us to release breaking changes? Do we mark them? Do we just silently update?

Do we consider CLI it's own thing and not bump the major in CLI when e.g. cli-style releases a breaking change?

[amcgee]

For this change I think the Node engine update is the breaking change, the fs-extra change doesn't change anything for the user of the CLI. I think that's the general philosophy for me - if a user of cli might have written a script that would break because of a dependency change in cli, then that's a breaking change in cli (so if we clobber an existing API in cli-style, for instance, that's a breaking cli change. Adding a feature to cli-style is not). I don't know that we need to be SUPER strict about this for tiny breaking changes in dependencies, but generally should follow those guidelines

[amcgee]

Looks good, tested that the install breaks when using Node v8. The CLI will still run with non-compliant Node versions if it's already been installed, though - we should look into adding something like check-engine (that one's a bit older) to cli-helpers-engine so that we always check the Node and Yarn versions match what we need.

[amcgee]

BREAKING CHANGE: Require Node version 10 or later.
BREAKING CHANGE: Update fs-extra to 9.x.

To conclude I think this is enough as the Breaking Change in the changelog (since it's the underlying reason for the fs-extra upgrade as well)

[amcgee]

Should we update the engine in cli-style, cli-app-scripts, etc. too?

[varl]

Should we update the engine in cli-style, cli-app-scripts, etc. too?

Yes.

[dhis2-bot]

🎉 This PR is included in version 3.0.0 🎉

The release is available on:

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

Your semantic-release bot 📦🚀