Create only-extend-defined rule

[TaeKimJR]

"only-extend-defined" ESLint Rule
Ensures that any extendable styles are defined in the component's style definition. This PR was created based on feedback on the extending styles PR.

Failing Example

export default withStyles(
  () => ({
    container: {
      background: 'red',
    },
  }),
  {
    extendableStyles: {
      container: {
        color: () => true, // would fail here
      },
      foo: { // would also fail here
        background: () => true,
      },
    },
  },
)(Foo);

[lencioni]

FWIW, adding this to the recommended list makes this a breaking change. Sometimes we add rules at first and then when we are ready to make a breaking change, we lump all of the modifications to the recommended config into one breaking change.

However, given how rarely we work on this particular plugin, it might make sense to do this now.

[ljharb]

might still be worth it to ship it as minor first (without this line) and then do a followup as a major that enables it.

[lencioni]

I think this raises an interesting question: should there be a rule to disallow computed properties for extendable styles (or for styles in general)?

[TaeKimJR]

I've seen a lot of usages of constants for things around responsiveness (e.g. [responsive.mediumAndAbove]). I think we would begin to limit ourselves a lot if we disallowed computed properties.

I wonder if we can ensure that the same variable is used in both places... I can take a look tonight.

[lencioni]

Ah right! Can we add some valid and invalid test cases for nested styles? Media queries, @supports queries, pseudo-elements, pseudo-selectors, etc.

[lencioni]

Same here, should spreading in extendable styles be disallowed?

[lencioni]

I think we can make this error message a little more helpful:

foo.background is not extendable because it is undefined

[lencioni]

Same here, add "because it is undefined" or something similar

[lencioni]

Should we have some valid and invalid examples where the functions use args?