Closed ITenthusiasm closed 1 year ago
Closing in favor of #310. However, we can re-open this if for some reason it seems more preferable.
:tada: This issue has been resolved in version 8.0.1 :tada:
The release is available on:
Your semantic-release bot :package::rocket:
Deleting this branch since #310 was merged.
Changes
afterEach
function instead of throwing errors.Why?
I gave some reasons for why I think this direction of change is desirable in #297 -- specifically here and here. But here's a brief set of reasons for why I think this is the way to go:
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 brittle because it only considersVitest
. 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 theif
/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 the existing check brittle). 3) Convention: AlthoughVitest
shares many similarities withJest
, 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. 4) Documentation: Both Vitest and VTL already document the fact that you must setupafterEach(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 mycleanup
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 while negating the point of the docs; so I feel it's best to avoid this.