Lint-staged: Drop support for Node v4

[okonet]

Description

Node will drop maintenance for v4 in April 2018 so I think we're pretty safe on dropping it now since I believe most of our users are early adopters either way. Supporting Node v4 right now is coming to an unwanted chores like in #367 or in #371.

Migration path

Introduce a breaking change with a major version bump that only changes engines field in the package.json + updates Travis config.

[okonet]

@sudo-suhas @luftywiranda13 thoughts?

[sudo-suhas]

I don't have any strong reasons against this but I'd prefer to drop support in April itself. lint-staged is a tool for developers and I would guess that a lot of repos probably won't be dropping node 4 support yet. That said, since this will be breaking change, they can choose to continue using the version compatible with node 4.

[luftywiranda13]

I agree with @sudo-suhas. Let’s drop support for node 4 when node drops supports for it

[okonet]

@luftywiranda13 I don't see a reason for us to wait and have pains since this will be a breaking change that will indicate that Node v8 is required for it to run so people can choose the previous major version which is fully functional. As @sudo-suhas mentioned as well, breaking change should remove the confusion IMO.

[luftywiranda13]

I personally have a plan to drop support for node 4 as well in some of my projects.
But sometimes I feel it's ironic that our devDependencies (not direct dependencies) force us to drop support for node 4 especially if we're not using any specific features that require node 6+

[sudo-suhas]

Right now, I think we have a couple of other breaking changes being discussed:

• Change the format for the config. This was brought up in #273 but I am not entirely sure what the final config schema would look like.
• Drop support for npm scripts and instead require the user to use npm run script-name -- (or the yarn equivalent).

At the very least, I'd prefer it if we didn't make 3 different breaking changes including this one. A good idea might be to use the next tag/branch and get valuable feedback from users until April before merging it into the master branch.

[okonet]

@sudo-suhas we could create the next branch but this means more setup for CI and more work for us. I don't have much time ATM so I'm trying to remove as much work as possible which isn't necessary. I don't feel strongly about either approach just saying if we can keep it simple, I'd prefer the simpler version.

[luftywiranda13]

how about if we make a next branch, then merge those breaking changes into this next branch (not to master).
after that, make a PR from next branch then we can press rebase and merge from the PR.

so semantic-release will release those breaking changes in a single release. I do this whenever I want to avoid releasing multiple breaking changes in my project

[okonet]

Yes that would be the plan. The problem with it as I see it is that we won't be able to do @next releases automatically on a separate channel. If this isn't a problem, then let's do that.

[sudo-suhas]

Isn't this all that is required:

_package.json_

{
  "...": "...",
  "publishConfig": {
    "tag": "next"
  },
  "release": {
    "branch": "next"
  },
}

See semantic-release/semantic-release:package.json@v12.2.0#L109-L114

[sudo-suhas]

[email protected] allows to skip release via commit message - https://semantic-release.gitbooks.io/semantic-release/content/docs/support/FAQ.html#can-i-exclude-commits-from-the-analysis.

Edit: Probably won't be useful. I don't think it can be used to delay releases.

[okonet]

I couldn’t find anything with commit message there and also don’t think we should do something like this. Let’s create the next branch and use it as a pre-release target if we want batching. But before we do, what’s the point of doing it, again?

[sudo-suhas]

Looks like greenkeeper build for push is failing during greenkeeper-lockfile-update on node 4 - https://travis-ci.org/okonet/lint-staged/jobs/329309633#L490. This doesn't happen on the PR build:

This build should not update the lockfile. It could be a PR, not a branch build.

https://travis-ci.org/okonet/lint-staged/jobs/329309702#L495.

Considering that it is becoming more and more cumbersome to support node 4, I vote to drop support. Unless somebody objects, I'll create a next branch, make a PR for dropping node 4 support and another for removing the run npm script functionality. Then we can release both in a single release.

[luftywiranda13]

For the lockfiles problem:

https://github.com/greenkeeperio/greenkeeper/issues/569 https://github.com/greenkeeperio/greenkeeper/issues/506

[luftywiranda13]

For the engine mismatch, the installation will only fail when we install dependencies by using yarn, right? With npm, it'll only log the status as a warning, not error. Also, IMO npm has a lot more users (npm is the default package manager for node) than yarn

jest set its minimum engine to node: >=6, so this thing only affects us in development, but not our end users.

So I still don't consider dropping support for node4 is a thing we should do right away, as long as we're using dependencies (not devDeps) that hasn't dropped support for node4.

Am I missing something here?

[okonet]

What's the point of supporting Node 4? We'll be doing a major release anyways so we're not disabling Node 4 users from using the tool in any way. Since this is an open source project everyone doing in it's free time, I'm voting for reducing the chore => drop support for Node 4.

[sudo-suhas]

As a side note, npm 5 was not usable on Windows last when I checked. yarn is faster and I'd really prefer to not be forced to use npm.

[okonet]

Since I'm actively working on #75 I'd really like to reduce the amount of code needed with Promises and switch to async await which is Node 8. Is that a common thing to go to latest LTS version (8) when dropping Node 4 or we'll need to support Node 6 as well? I'd like to skip Node 6 whatsoever.

[sudo-suhas]

Would you consider transpiling src files? I think dropping node 6 support would be premature.

[okonet]

@sudo-suhas I really don't want to transpile the code since it makes it's harder to test locally. Is there a usage information for different Node versions? What are other libraries are doing?

[jaydenseric]

Unfortunatly AWS Lambda only supports Node.js v6.10.3. For a while I was enjoying supporting v7.6 for my packages, like Koa does, for native async await but some users ran into trouble. I don't know if Lambda is a consideration here or not.

[okonet]

Since lint-staged is meant to be used only during development, I'm not sure if AWS support should be considered as an issue...

[jaydenseric]

Probably, although some people might develop with the version of Node.js their app will run in production.

[sudo-suhas]

I really don't want to transpile the code since it makes it's harder to test locally.

If we assume that _transpiling itself_ won't be the source of the issue, we could develop and test with node 8 but the published module would work fine on node 6. I personally haven't really faced issues because of transpiling but I do not know if that can be assumed.

Is there a usage information for different Node versions?

check this out - https://nodesource.com/blog/digging-into-node-by-numbers-2017

Throughout the year, you can see Node.js 6 reigning supreme—peaking at 388,417 downloads on October 25th. Unlike last year with Node.js 6 and Node.js 4, the downloads of Node.js 8 didn’t surpass the downloads of the Node.js 6 LTS. This is an interesting trend that we should watch into the new year. It seems that the majority of downloads of Node.js are still Node.js 6, even though Node.js 8 has been trending upward for the past few months.

[sudo-suhas]

Here's another blog post for node.js usage stats - https://semaphoreci.com/blog/2017/11/22/nodejs-versions-used-in-commercial-projects-in-2017.html

[okonet]

If we assume that transpiling itself won't be the source of the issue

I guess if we'll assume this, there is a chance of running into issues where the report bug reports (i.e. stack traces) won't match the source code and will make it harder to debug.

[okonet]

The way I think is summarized in this article: https://medium.com/@mikeal/stop-supporting-old-releases-70cfa0e04b0c

[sudo-suhas]

@okonet, how about this. I am willing to take responsibility for the development and support overhead we might incur if we use transpilation. I agree that no transpilation is better but I feel this is a compromise I can accept as opposed to min node 8 requirement.

[okonet]

as opposed to min node 8 requirement

Intermediate results from the poll:

¼ is still using Node 6 but I guess they could stick to the current major version or upgrade. I'm still not sold on us doing extra work. But if you think this won't affect DX when let's do this.

[sudo-suhas]

@okonet Have you tried tj/co? I had used it to good effect in some projects before node 7.6.

[okonet]

@sudo-suhas no I honestly I don't want to start using it—the syntax is weird IMO.

My conclusion is still the same: I don't want to please everyone, especially when doing this for free. So if the 25% of users will have to stick to the older version because of that, I'm okay with that. They also can upgrade to Node 8, which is a win-win for everyone.

So I'm voting for dropping Node 4 and going straight Node 8.

[okonet]

This can be closed since we now require Node >=6 and when #75 is merged it's going to be v8