Update eslint to version 3.0.0 🚀

[greenkeeperio-bot]

Hello lovely humans,

eslint just published its new version 3.0.0.

State	Update 🚀
Dependency	eslint
New version	3.0.0
Type	devDependency

This version is not covered by your current version range.

Without accepting this pull request your project will work just like it did before. There might be a bunch of new features, fixes and perf improvements that the maintainers worked on for you though.

I recommend you look into these changes and try to get onto the latest version of eslint.
Given that you have a decent test suite, a passing build is a strong indicator that you can take advantage of these changes by merging the proposed change into your project. Otherwise this branch is a great starting point for you to work on the update.

Do you have any ideas how I could improve these pull requests? Did I report anything you think isn’t right?
Are you unsure about how things are supposed to work?

There is a collection of frequently asked questions and while I’m just a bot, there is a group of people who are happy to teach me new things. Let them know.

Good luck with your project ✨

You rock!

🌴

---

This pull request was created by greenkeeper.io.

_{Tired of seeing this sponsor message? ⚡ greenkeeper upgrade}

[Starefossen]

peerDependencies also needs to be updated. Also, maybe use ^3.0.0 for version range?

[benmosher]

Ah, yeah, need to update peerDependencies to >=2.0.0. Should have done that from the beginning.

[Starefossen]

Great 😄 Thanks for making this awesome plugin @benmosher 👍🏼

[ljharb]

I wouldn't be so confident that major version changes will never break things. The proper thing to do imo is manually update major versions each time one is released.

[benmosher]

@ljharb I generally agree with you, but in this case, as a plugin for a tool with a peer dependency, I think it's okay to play it a little looser/optimistically. Had I done that before, everything would have just worked instead of the cascading delays as plugins update the relationships (and are forced to upgrade for no reason other than dependency declarations).

Different story for library-dependency relationships, I think. I can see it going either way. And I might not have said any of this had there been breaking changes in the plugin interface. 😅

[benmosher]

Aaaaand I just found the page about the new rule format. 😅 (http://eslint.org/blog/2016/07/eslint-new-rule-format)

[benmosher]

So the current plugin is almost definitely not going to work in ESLint 4.x. So 2-3 is the correct range. (At least for now...)

[ljharb]

this should probably be 1.11.0 since it's a new thing, not a bugfix

[benmosher]

I was thinking 1.10.1 because there are no new features, only difference is (officially declared) compatibility with ESLint 3.

[ljharb]

That is a new feature.

[Starefossen]

Yes, it is a new feature but not for the public API exposed by the eslint-plugin-import package which is what SemVer applies to in this instance.

On 3. juli 2016, at 17:10, Jordan Harband notifications@github.com wrote:

In CHANGELOG.md:

@@ -5,6 +5,11 @@ This change log adheres to standards from [Keep a CHANGELOG](http://keepachangel

[Unreleased]

+## [1.10.1] - 2016-07-02
That is a new feature.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[ljharb]

The peerDependency list is part of the public API exposed by any package, since it requires explicit developer interaction (manually installing + updating the peer dependency).

[Starefossen]

I think 1.10.1 is fine. Both versions seam equally correct according to the SemVer specification:

1. Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior.
2. Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.

[benmosher]

Published as v1.10.1 to npm.

[benmosher]

Ugh, heads up: something bizarre happened with the publish of 1.10.1... I think I may have published unfinished v2?

Hard-cleaned build products and rebuilt + published again as 1.10.2. 😳

[ljharb]

Thanks, good to know. npm deprecate eslint-plugin-import@1.10.1 'bad publish, use 1.10.2'?

[benmosher]

I asked support to yank it. I'll do that too