Revert Errors Regarding Missing Global Hooks

[ITenthusiasm]

This PR effectively reverts the changes in #297, and it serves as the ideal over #309. Note that I've had my changes reverted before and I know it isn't the most pleasurable experience. So please hear out my justification for this suggestion. It's not a petty change. It's a change that I believe benefits the VTL users overall. (Some of the points below are mentioned here and here in #297.)

Justification

1) Developer Experience. Throwing errors at developers who intentionally don't use globals is a really painful DX. Yes, there are workarounds, but any workaround for this problem will admittedly be clunky (and therefore another bad DX). 2) Fragility. The current implementation of the afterEach absence check is very limited because it only considers Vitest. If we're thinking about the longterm strength of this project, it needs to be able to consider all possible test runners. Only considering one test runner is insufficient, and bloating the if/else checks for every new test runner that gets released will eventually become unmaintainable. Moreover, since it's an internal implementation detail, Vitest can change the ENV variable that they use at any moment (again, making our existing check brittle). 3) More Fragility. We have our current expectations about the future based on past experiences. But there's no saying that a hot new test runner that doesn't use afterEach will never appear. If that ever happens, throwing/logging errors/warnings when afterEach is missing will simply be inaccurate. 4) Convention: Although Vitest shares many similarities with Jest, it also has some intentional differences. For instance, Vitest intentionally refuses to use globals by default. To create a scenario in VTL that requires Vitest users to use globals (by default) goes against the natural flow of Vitest, and it may disrupt several Vitest users in the process. 5) Documentation: Both Vitest and VTL already document the fact that you must setup afterEach(cleanup) manually if globals are not available for your test runner. The point of the documentation is to catch these exact pitfalls. If the people migrating from Jest to Vitest aren't using the Migration Guide, and if the people using VTL aren't reading the VTL docs, then there isn't really much that the maintainers can accomplish for their users. The docs are very accessible. (I used them to handle my cleanup errors.) But the developer still has to reach for them. And maintainers can only go so far without harming other developers' experiences (e.g., throwing errors when globals aren't available) or making the logs/JSDocs overwhelming. Throwing errors harms DX and negates the point of the docs; so I feel it's best to avoid this. 6) Consistency in the Testing Library Family. To my knowledge, no other testing library tool throws errors or logs warnings when the global afterEach function is missing. So to include such functionality in VTL will be unexpected for many developers. Originally, I opened #309 in light of testing-library/react-testing-library#1252. However, this change was reverted in testing-library/react-testing-library#1255 for reasons similar to what I mentioned earlier. This is why I closed #309 and am opening this PR.

---

I think what we're experiencing right now is a season in which developers are trying out new testing tools besides Jest. And having been used to things generally "just working" for so long, there may be some who do not prefer to reach for the documentation. However, the documentation is there for a reason. In Open Source, there are some GitHub Issues that get opened, but that ultimately just get closed with a comment saying, "We explain this in the docs". For this scenario, this should probably be the approach that VTL takes. Otherwise, we'll create a more difficult DX and an inconsistent TL experience for a set of VTL users -- eventually engendering issues like testing-library/react-testing-library#1253. (Again, the docs are exactly for this use case.)

[ITenthusiasm]

@afontcu Would highly appreciate it if you considered this. (I would also understand if you choose to reject it.)

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (88fb8cd) 100.00% compared to head (331b3ca) 100.00%.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #310 +/- ## ========================================= Coverage 100.00% 100.00% ========================================= Files 3 3 Lines 80 78 -2 Branches 29 28 -1 ========================================= - Hits 80 78 -2 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[ITenthusiasm]

Thanks so much for the help and consideration! 🙏🏾

[github-actions[bot]]

:tada: This PR is included in version 8.0.1 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: