Consider updating clients first before making changes to this repo

[mcmire]

Extension, mobile, and core are behind the current version of our ESLint packages to varying degrees, and the chance that upgrading ESLint or enabling a previously disabled rule will cause numerous lint violations is fairly high. As raised by @legobeat, we shouldn't add any new rules or make any modifications to existing rules until we bring them up to date. If we want to introduce a new rule to a project, we should consider only enabling it there and not on an org level.

[Gudahtt]

I assume this is regarding breaking changes only?

Most of our minor/patch releases here are meant to make updating easier.

[mcmire]

Yes, I think so.

I didn't do a good job of outlining the concerns here, but they are similar to what we have in core, which is that if we make a breaking change without testing it in other repos, particularly clients, then we won't understand the full effects of that change.

I suppose we could solve that by introducing a checklist like we do in core and asking contributors to make draft pull requests in clients whenever they introduce breaking changes.

[Gudahtt]

Lately I've been testing changes here in core before release, because extension is too far behind (and mobile doesn't use this repo at all).

It would be ideal to test changes here across all three eventually though, when we're caught up