eslint-plugin incompatible with ESLint 6?

[octogonz]

I see that the latest eslint-plugin/package.json seems to require ESLint version 5.x.x:

{
  "name": "@typescript-eslint/eslint-plugin",
  "version": "1.12.0",
  . . .
  "peerDependencies": {
    "@typescript-eslint/parser": "^1.9.0",
    "eslint": "^5.0.0"   // <------------ ???
  }
}

The ESLint 6 was released a month ago. Is @typescript-eslint/eslint-plugin only compatible with ESLint 5?

If it's known to be compatible, maybe we should update the peer dependency. The toolchain I'm using validates that peer dependencies are correctly installed, so this is preventing us from upgrading to ESLint 6.

[bradzacher]

See #645 - the search tool is your friend.

---

If it's known to be compatible, maybe we should update the peer dependency.

It's not as simple as updating the peer dependency. Updating the peer dependency implies that you are 100% tested against, and support that version. Without that PR, we do not test or truly support v6, so it is not a peer dependency.

Note, however, that the plugin will work fine. There is no breaking changes within v6 that break the latest versions of our plugin.

Releasing v6 support involves stopping support of node v6, which is a breaking change. We have a bunch of stuff of our own we want to bundle into a single breaking release, rather than causing churn and releasing another breaking change so soon after.

Details: https://github.com/typescript-eslint/typescript-eslint/milestone/2

We're almost ready to do the v2 release, it'll be coming soon.

The ESLint 6 was released a month ago.

We're a project run entirely by unpaid volunteers working in our free time.
As such, things get done in due time.

[GaryB432]

Thank you unpaid volunteers for work on this project! Just wondering... this and similar issues are summarily closed. Is there an issue or thread I could follow somewhere which would alert me when you eventually get around to this peer dependency in due time? Thanks again. Much love to the project.

[octogonz]

Updating the peer dependency implies that you are 100% tested against, and support that version.

This is not really how NPM packages work in general. Peer dependencies express whether something is compatible in principle, not whether that compatibility is fully supported by humans or bug free.

Why not relax the peer dependency and simply document that ESLint 6 support is experimental? That would communicate that it is not supported without hassling the people who are okay using an unsupported configuration. The package I'm creating is itself "experimental" but I'm blocked from publishing it due to this peer dependency. And it does indeed "work fine" as far as my testing so far.

[udanpe]

The package I'm creating is itself "experimental"

@octogonz
npm i -D @typescript-eslint/eslint-plugin@canary

[octogonz]

Awesome -- I didn't realize this was addressed in the canary version.

[bradzacher]

For v2 breaking changes and their statuses, See https://github.com/typescript-eslint/typescript-eslint/milestone/2 and #501

---

not whether that compatibility is fully supported by humans or bug free.

Wouldn't it be a bit disingenuous to falsely represent compatibility with a version, if there is not testing done or if it has known bugs?

For example, there were actually 4 or 5 bugs that were introduced with v6. These bugs hard crashed the plugin, and made it unusable with v6.

If we had just bumped our peerDeps range without testing, then we would have unknowingly published a completely broken experience to users of v6.

We've got 1mil weekly downloads of each of the packages in this repo. That's too many users to be announcing support before it's known good.

[octogonz]

When I wrote that, I didn't realize that the canary version allows ESLint 6, so the policy seemed to prevent usage of ESLint 6 at all. Allowing ESLint 6 only in the experimental version makes perfect sense, so please disregard what I said. 👍