Extending multiple configs can cause conflicts

[Bryan Mishkin]

Let's say a consumer extends two of our configs like this:

extends: ['plugin:square/ember', 'plugin:square/typescript']

Here's an example of a problem that can happen:

1. ember config loads which extends the base config:
   1a. base config turns various linting on including the array-callback-return rule
   1b. ember config configures various linting including turning off the array-callback-return rule off for a certain file
2. typescript config loads which extends the base config:
   2a. base config loads again which turns the array-callback-return rule BACK ON everywhere (this breaks the intended behavior of the ember config)
   2b. typescript config configures various linting

Possible fixes:

1. Stop extending base config automatically with all our configs. That would then require consumers to specify the base config first before other configs would they might forget to do.
2. Somehow prevent the base config from being loaded multiple times (if it could detect that it has already been loaded by a previous config).
3. ?

[Max Beatty]

One possible alternative would be to always respect the config you are extending ("append only"). This is difficult if you aren't super familiar with the config being extended and may be more of a design aspiration.

Another idea is to keep them scoped to their specialty like Ember, React, or TypeScript. That may help find the right home for a rule.