ESLint plugin Testing Library v4

[Belco90]

I'd like to keep everything planned for v4 update here, so it's easier for everyone involved to organize pending work. This was started in #165.

Changes planned for v4:

• new rule: no-container - new rule: no-container #171, feat: add no-container rule #177
• new rule: render-result-naming-convention - new rule: render-result-naming-convention #170, feat: add render-result-naming-convention rule #200
• new rule: prefer-user-event - New rule: prefer-user-event #162, [new-rule] prefer-user-event #192
• new rule: no-promise-in-fire-event - fireEvent with Promises #166, feat(no-promise-in-fire-event): add new no-promise-in-fire-event rule #180
• new rule: no-wait-for-side-effects - new rule: no-side-effects-wait-for #134, feat: add rule no-side-effects-wait-for #196
• new rule: no-node-access - feat: add no-node-access rule #190
• new rule: no-wait-for-multiple-assertions - new rule: no-multiple-assertions-wait-for #133, feat: add rule no-multiple-assertions-wait-for #189
• BREAKING CHANGE: enable no-wait-for-empty-callback in config presets - feat: recommend no-wait-for-empty-callback #168
• BREAKING CHANGE: enable prefer-screen-queries in config presets - feat: recommend prefer-screen-queries #169
• BREAKING CHANGE: rename recommended config to dom - Rename recommended config #182, refactor: rename recommended config to dom #184
• BREAKING CHANGE: move rules settings to ESLint shared config - Move rules settings to ESLint shared config #198
• ci: migrate CI to GitHub Actions

Extra:

• Cleanup after all rules are migrated: refactor: cleanup after migrating all rules to v4 #303
• Update README with shared settings: docs: update README for v4 #317
• Update README to explain "aggressive mode", its motivation and how to restrict its scope: docs: add guide for migrating to v4 #312
• Update rules docs to delete references to removed options
• Update CONTRIBUTING to mention new rules creation + detection helper + realistic test cases: docs: update contributing guidelines to v4 #321
• Write migrating to v4 guide: docs: add guide for migrating to v4 #312
• Prepare release notes

Future Improvements:

• Allow multiple utils modules on Shared Settings: Allow multiple utils modules on Shared Settings #315
• New rule: no-unnecessary-act - add no-unnecessary-act rule #259

Thanks to @gndelia @timdeschryver @nickmccurdy @thebinaryfelix @renatoagds for your work on this one!

[Belco90]

Do you think we need to wait for those 4 new rules for releasing v4? I think render-result-naming-convention and prefer-user-event are necessary, but we could release prefer-user-event and no-multiple-assertions-wait-for in a later step?

[nickserv]

We could also assign issues from the milestone.

[Belco90]

Yeah I just felt I needed a place to see everything together but also be able to discuss what's needed and coordinate this better.

[nickserv]

Do you think we need to wait for those 4 new rules for releasing v4? I think render-result-naming-convention and prefer-user-event are necessary, but we could release prefer-user-event and no-multiple-assertions-wait-for in a later step?

I guess that depends on if we want to make them recommended, and I think they probably should be. As long as it doesn't take too longer to work on them, waiting to release them would reduce the number of breaking releases and potentially make upgrading easier. Alternatively we could make the migration more gradual and maybe release rules in 4.x but only recommend them in 5.x.

[Belco90]

Mmm I wasn't thinking about releasing new rules included in config presets as major. I see including rules in preset as a major only when they existed before, but not if they are gonna be completely new rules. Again, I don't know how we should address this.

[nickserv]

Both adding an existing rule and adding a new rule to a config change the config to make more use cases fail, which I see as a breaking change either way. So I think we'd either need to wait for these to be in v4 or have them in a future major release if we don't enable them in v4, but I was asking more about how we'd release the rules themselves and change the configs.

[nickserv]

Maybe we should make suggestions about new features warn rather than error to make it easier for users to migrate.

Relevant discussions:

• [new-rule] prefer-user-event #192 (comment)
• feat(eslint-config-react-app): Add jest & testing-library rules facebook/create-react-app#8963 (comment)

[Belco90]

Maybe we should make suggestions about new features warn rather than error to make it easier for users to migrate.

Relevant discussions:

* [#192 (comment)](https://github.com/testing-library/eslint-plugin-testing-library/pull/192#issuecomment-652529480)

* [facebook/create-react-app#8963 (comment)](https://github.com/facebook/create-react-app/pull/8963#issuecomment-652398748)

I guess the candidates for that would be:

• prefer-user-event
• no-side-effects-wait-for (when implemented)
• no-multiple-assertions-wait-for

Any other rule I'm missing?

[renatoagds]

@Belco90 Maybe no-container too? Looks like something good to have as default in CRA.