Update eslint-config-airbnb to version 11.0.0 🚀

[greenkeeperio-bot]

Hello lovely humans,

eslint-config-airbnb just published its new version 11.0.0.

State	Update 🚀
Dependency	eslint-config-airbnb
New version	11.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-config-airbnb.
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}

[kumar303]

Due to a bug (jsx-eslint/eslint-plugin-react#816) triggered by our use of destructors, we can't specify the real shape of the objects we depend on. This isn't such a big deal to me because static prop type checking has so many flaws already.

[kumar303]

@mstriemer could you take a look since there are quite a few changes?

[mstriemer]

I think I'd prefer that we change react/forbid-prop-types to allow object rather than use shape({}) all over. Do we expect that we'll actually define what the shape is?

[muffinresearch]

I agree, it feels like changing to shape with an empty object is sort of sweeping the issue eslint is detecting under the carpet and if we're going to do that, we might as well relax this rule.

One thing I did find playing around with this is that the detection of shape props is a bit limited so as soon as you start using it you'll find you need to relax one of the unused props rules (to ignore shape props) because the current rules fail to detect the usage of the props as soon as you alias the object (which is a common pattern with destructuring).

Overall, I like the idea of a warning when someone uses object as its good to get into the practice of properly specifying the object shape. However, doing that is only really useful if using shape will provide warnings if the props aren't used or don't match up. What I'm not sure of is what the console will tell us via react's dev warnings vs these lint warnings.

[mstriemer]

Looks good. I'd like to avoid the noise on the shape({}) change. I'd also rather write object than shape({}) and I'm not convinced we care about prop types enough to make proper use of shape().

Is there some advantage to defining the shape that I'm missing?

[mstriemer]

r+wc

[muffinresearch]

I was curious so I looked this up. Static methods in JS have access to this. E.g you can call another static method from a static method, or access other static properties.

But, static methods are only enumerable as properties of the class object. You can't call a static method as a property of an instance (unlike Python which allows both). Because of that the this in a static method is a reference to the object and not ever the instance.

See http://jsbin.com/dubelog/edit?js,console for an example.

It makes sense we don't want to start converting methods that don't use this into static methods because that will probably cause breakage.

[kumar303]

yeah, I was playing with this too. I can't think of any case where we'd want to make a react component's method static if that method is used by render(). Maybe AirBnB had this rule because they don't use lifecycle react classes? I know stateless components is all the hotness.

[kumar303]

The problem with object is that pretty much anything satisfies that PropType. If we use shape() everywhere then we have to explicitly define what kind of object we accept and theoretically this will catch incompatibilities (especially in refactoring).

Now, enter the real world:

• The use of shape() is broken for most of our code because of Destructured use of property is not recognized by no-unused-prop-types jsx-eslint/eslint-plugin-react#816 (but this looks like it will be fixed soon)
• We cannot import shape types because of Follow imported PropType objects jsx-eslint/eslint-plugin-react#817 (which doesn't look like it will be fixed) so our code will get very verbose very fast.
• As far as I can tell, external usage of components isn't checked by the linter, only internal usage (not so interesting.

So, yeah, I'll remove shape() for now but I personally would love to add it back in if some of these bugs get fixed. I've found this kind of static analysis to be really helpful when refactoring.

[muffinresearch]

Left over shape

[kumar303]

sorry, just got busy. I haven't removed them all yet.

[kumar303]

oh, hah, I did remove them! And I did indeed forget these, thanks.