Drop Node 4 support (and Node 6 and Node 8)

[lipis]

The official support for Node 4 is ending soon (April 2018) and from time to time we have quite a few issues like #3875 with the failed automated tests.

What can possibly go wrong?!

(It was also discussed in the #3503, but I'm not sure how far we are with that one)

[lipis]

Already discussed: #3503 (comment)

[j-f1]

I still think we should do this, although we might want to give people a little time to migrate away from the soon-to-be-insecure Node 4. On the other hand, since Prettier doesn’t go into production code (unless I’m missing something), we could move on and say that people who need Node 4 support can just use an older version of Prettier with Node 4 support until they can migrate.

[alexander-akait]

I agree, some parsers can require minimum nodejs 6 and problems will be corrected only for the version 6 version

[duailibe]

I think we can "oficially" drop support for node 4, but not necessarily we have to make it stop working for node 4.

[j-f1]

How about switching Travis to 6/node instead of 4/node?

[TrySound]

stable is deprecated use node instead
https://github.com/creationix/nvm#usage

[j-f1]

Thanks for pointing that out @TrySound! Fixed.

[duailibe]

@j-f1 Actually I was thinking about still running node 4 tests, but maybe installing the dependencies with --ignore-engines (only for node 4) and see if it still works.

[azz]

A concern is that libs using Prettier still support Node 4, and they'll be running Prettier in their CI on Node 4.

[TrySound]

Maybe this users should just use current major instead of the next one?

[suchipi]

I don't think it's safe to drop node 4 support without bumping to 2.0.

[duailibe]

@azz @suchipi What if we only support node 4 in the published build?

i.e. we'll stop supporting people installing prettier directly from the repo using node 4, which I believe it's unusual

[suchipi]

That sounds reasonable. Then we could transpile for npm, but only have the src in the git repo. Great solution

[duailibe]

I don't even mean transpiling our own code, just our dependencies (so we'd still use node 4 supported syntax). If users want to install directly from the repo they can use the "ignore engine" yarn feature (or npm if they have that too) - if the dependency still works.

[duailibe]

Babel has already dropped Node 4 support so we'll have to do something because we'll eventually need to upgrade babylon

[brodybits]

I am looking forward to this idea, which would need to be done in a major release such as 2.0 (#3503). I find it really ugly cryptic (non-obvious) that package.json specifies "node": ">=6" while generated dist/package.json specifies "node": ">=4".

[duailibe]

@brodybits why is it ugly? I believe our current solution works fine

[brodybits]

Let me rephrase it to "cryptic (non-obvious)" then (I already updated my comment). I am looking forward to the new release, with no Node.js 4 support baggage. A side point is that Node.js 6 maintenance will end pretty soon, as I reported in #5711.

[j-f1]

We’ll probably drop Node 6 support when Node does, but not for the production version.

[duailibe]

I believe the majority of our users won't even know (or care) that we have different configurations. I'm obviously biased but I don't see any downsides in doing that (or benefits removing it).

I don't have any data on Node 4 usage, but if it's not too much trouble to continue supporting it for the near future, I don't see a problem with it

EDIT: there are a few problems, like updating libs (like Jest) but we were able to workaround them.

[duailibe]

I really wonder is there anyone install prettier from this repo instead of install from npm?

@fisker We have explained this numerous times already but here it is:

1. we'd like to easy support for forking Prettier and so people can just fork and install directly from their fork
2. we want to make it easy for people to use fixes and features in master before we cut a new release

we should not support that

@fisker Why not?

[brodybits]

@brodybits What are the dependencies that are incompatible and why do we need to update them?

get-stream@5.1.0 was one; I thought there were some others. I would have to check again.

Outdated dependencies can miss security updates and other bug fixes. Outdated dependencies can also be harder to update in the future.

there anyone install prettier from this repo
[...]
we should not support that

@fisker Why not?

• additional testing burden
• makes it harder to update dependencies without breaking this functionality

I would personally favor we support this functionality for recent Node.js versions only.

[fisker]

Outdated dependencies can also be harder to update in the future

Agree, last time when I try to upgrade rollup, I have to look for very old docs and issues and changlog

[fisker]

we'd like to easy support for forking Prettier and so people can just fork and install directly from their fork

why not fork, change, build, install from bundle? this is what I would do, if I want to change something

[duailibe]

Outdated dependencies can miss security updates and other bug fixes. Outdated dependencies can also be harder to update in the future.

@brodybits Maybe, but practically that hasn't happened. All the "security updates" GitHub warned so far didn't affect us at all. Specially since this project is just a formatter.

I would personally favor we support this functionality for recent Node.js versions only.

@brodybits There may be people running a forked Prettier in CI's with old Node.js versions.

Agree, last time when I try to upgrade rollup, I have to look for very old docs and issues and changlog

@fisker Was it necessary to update rollup though? Did we have any benefits from upgrading it?

why not fork, change, build, install from bundle?

@fisker How to install from bundle? Where will you keep this bundle?

[fisker]

Was it necessary to update rollup though? Did we have any benefits from upgrading it?

@duailibe You're the one want it updated #6154 #6200

[alexander-akait]

@duailibe some parsers can drop support node@4 and it will be problem for us

[duailibe]

@fisker Forgot about that 👍 The comment is valid for everything else

@evilebottnawi There are some dependencies that have dropped support and that doesn't affect us because we transpile everything.

And I'll repeat:

Dropping Node 4 is already planned, but it's a breaking change, it'll go out with 2.0. It needs to be coordinated.

I'll release 1.19 soon and then start the necessary changes for 2.0.

[j-f1]

@duailibe You dropped Node 4 support for installing Prettier directly from GitHub. Do you think it would be reasonable to also drop Node 6 support for direct-from-GitHub installs?

[brodybits]

Do you think it would be reasonable to also drop Node 6 support for direct-from-GitHub installs?

I would personally consider this to be a breaking change if we want to be strictly semver compliant, which I would favor.

I really hope we can start targeting the new major release and update the dependencies soon. Supporting the old Node.js versions seems to divert attention and resources away from highly desired updates and bug fixes.

P.S. I am taking back my comment about the breaking change since install from GitHub is an undocumented feature (typescript-eslint/typescript-eslint#1108 (comment)). But my comment about supporting old Node.js versions continues to stand.

[sosukesuzuki]

#6907 #6908 #7302 has been merged into next.
What else should we do for this issue? Or can we close this issue?