Prettier and node v6 support

[bradzacher]

See: prettier/prettier#6595 (comment)

Prettier currently uses 1.13.0 of @typescript-eslint/typescript-estree.
In order to support the new syntax in TS 3.7.0, they will need to upgrade to >=2.4.0.
However in 2.0.0, we dropped support for node 6 (following eslint's lead, as the version was EOL in April).
Prettier is currently stuck supporting node v6 until they do their 2.0 major release.

We need to figure out a solution for this, or else our users will suffer in not being able to use optional chaining / nullish coalescing with prettier + TS.

I see a few choices:

• We add explicit support for it back to typescript-estree.
  • Easy for us to do (ready to raise a PR), but means we will have another breaking change to drop support for it (again).
• We publish a v6 clone of typescript-estree, which is no different, apart from the supported node versions (i.e. it would just be a build step to copy the dist folder across).
  • A little more overhead for us as it's another package to publish. Avoids the breaking change problem.
• Prettier maintains a separate fork of the package with explicit support.
  • A lot of overhead and will cause frustration. Do not recommend.
• Prettier documents that you must have node 8+ if you want typescript support.
  • Could cause some issues/misunderstandings for users, increasing maintenance overhead for both packages.
    • Users don't understand the separation between the packages. Case in point the bug reports we received when 3.7.0-beta released, because eslint-plugin-prettier errored out.

This issue is to discuss the best course of action.
Tagging some additional folks just to get some input from people who have more experience maintaining open source packages than I do (please, and thank you in advance 😄)

@JamesHenry, @thorn0, @platinumazure, @kaicataldo, @j-f1

[kaicataldo]

Do we know when Prettier is expecting to do another major release (if that’s known)?

The first two options seem like the best way forward to me, since neither adds a ton of overhead for this project’s maintainers and don’t require anything of end users or maintainers of consumer packages. If it can be automated, I would advocate for publishing a separate version that explicitly includes Node v6 support.

Could it be possible to release this other version as a continuation of the last major version that supported Node 6? I think that would make sense semantically (thought I’m not sure of what other breaking changes exist or what this project’s semver policy is) and would allow us not to publish an entirely separate package that would then need to be deprecated.

[bradzacher]

Do we know when Prettier is expecting to do another major release (if that’s known)?

I think they want to get to working on it after the next minor (prettier/prettier#6680 (comment)). I'm sure @thorn0 might have more of an idea.
Unless they're quick, it'll probably be after the full ts 3.7.0 release (they usually let the beta stew for ~2 weeks and it's been out since Oct 1).

If it can be automated, I would advocate for publishing a separate version that explicitly includes Node v6 support.

No doubt it can. @JamesHenry has more of an idea about the scripts involved, but I think it's as simple as setting it up in the repo + lerna config, and it'll publish.

Could it be possible to release this other version as a continuation of the last major version that supported Node 6?

Uhhh technically, yes, but it'd probably be a large PITA to manually work the changes into the old code.

[kaicataldo]

Uhhh technically, yes, but it'd probably be a large PITA to manually work the changes into the old code.

Would we need to? Is there any way we could create a fork of the current code, update the version in package.json manually (to 2.x or whatever it needs to be), and tag it? I haven't done this before, so not sure how feasible that is...

[thorn0]

Do we know when Prettier is expecting to do another major release (if that’s known)?

Not really known. 'A non-ambitious 2.0' here is a plan B. It might happen pretty soon if we don't find another solution for this Node 6 issue. Dropping Node 6 might even be its only breaking change. Not a desirable scenario, but still better than maintaining a fork of typescript-estree.

On the other hand, Prettier has 'the ambitious 2.0' plan, which has been discussed for quite some time. It should bring many breaking changes at once to simplify migration and minimize user base fragmentation that multiple major releases can cause. There is still seemingly no consensus about some of those changes, so I think it's safe to say it's not going to happen this year.

[bradzacher]

Would we need to? Is there any way we could create a fork of the current code, update the version in package.json manually (to 2.x or whatever it needs to be), and tag it?

Yeah, there were more breaking changes than dropping v6, so we can't just release the current codebase as a v1.14.0. I'd have to cherry pick the relevant commits across, and then manually fix up the problems. It'd be pretty involved.

---

I'll look into doing option 2: We publish a v6 clone of typescript-estree, which is no different, apart from the supported node versions.

I don't really want to introduce back node v6 support into the main package, because it will force us to do another breaking change to remove it.
It should, however, be completely trivial for us to add a build script which copies the dist across to a new package.

That way you get an in-sync version with testing against v6, and all we need to do is deprecate the package + delete the code when you guys are ready.

[thorn0]

@bradzacher Before you do anything, I must notice that we're talking only about Node 6 support for the scenarios where Prettier is installed directly from GitHub (explanation, more details). The versions released on npm support even Node 4 because they're transpiled. When I asked you to consider adding back Node 6 support, I meant your option 1, supposing you're okay with it. As you're not, let's just close this issue. It's not worth the trouble. That install-from-GitHub workflow is not even documented anywhere, so strictly speaking, dropping Node 6 support for it is not exactly a breaking change. Actually, we even have a precedent: Node 4 was dropped for it without incrementing the major version.

[lydell]

If you’re running an old Node.js, then you’re probably not running the latest of any packages either. I think it makes sense to only support newer Node.js for direct GitHub installs, for those who use the latest and greatest of everything.

[thorn0]

Exactly. And those hypothetical 'people running a forked Prettier in CI's with old Node.js versions' (from here) should first pull changes from the upstream to break their CI. And if they do so, they can as well update Node. Nothing is going to break suddenly by itself. It can break only if someone installs from prettier/prettier#master, but why would anyone do this?

[bradzacher]

Sounds good! Based on that conversation, I'll close this as no action.