Hi @vansergen . So I think it's good, with some changes:

1. There is no need to drop Node.js support for a dev dependency; the CI scripts should just be updated to use that on the needed Node.js versions.
2. The goal of this project is to change everything to StandardJS format. If there is going to be massive changes to the source (as it seems from the second commit above), we should just change to StandardJS fully at this point.

Either way (original or 2 above), we need to determine what the plan of landing will actually be, as it seems like the suggestion here is requiring massive changes to the source code, which I would presume would make a lot of our in progress PRs no longer mergeable, right? That would throw a large wrench into the final efforts of 5.0, so may be worth waiting to perform this until after 5.0 is first release, maybe?

@dougwilson What is the point to keep support of Node <10 (#2755 (comment)) on 5.0 branch?

If you want to move forward to StandardJS, maybe we should add eslint-config-standard to devDependencies?

What is the point to keep support of Node <10 (#2755 (comment)) on 5.0 branch?

None, but if we can possibly target master, that would be best, as we will need to keep merging 4.x into 5.0 over the next year as we support it, so if these changes are going to break mergeability, we should have a clear reason why it cannot go into master (4.x).

If you want to move forward to StandardJS, maybe we should add eslint-config-standard to devDependencies?

Yep

If we are going to reformat all the code in one go, we'll definitely do that in it's own PR. If we want to do that at some point, we could, but past conversations I'm aware of have decided to only apply formatting changes to the pieces of code touched in each commit, to avoid overwriting the entire blame history of the project.

Not super relevant but version 15 of eslint-config-standard will be the one to support ESLint 7, my plan is to release it in the coming days: https://github.com/standard/eslint-config-standard/issues/171

Still, I think that we should use some tool to only lint changed lines of code, since otherwise we will break merging between e.g. 5.x and 4.x, and loose all blame information.