test: add type notation in tests

[Tlacenka]

Upon discovering one can use a type argument in toEqual and toStrictEqual, I added these arguments in our tests. They replace the need for satisfies in expected test output.

Note: The type argument cannot be used when the output from expect is a promise that requires a resolves first.

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit 5641b0e. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this CI Pipeline Execution

---

✅ Successfully ran 9 targets

• nx run-many --target=deploy --dry-run
• nx version @code-pushup/cli-source --dryRun
• nx affected:e2e --parallel=3
• nx run-upload
• nx run-collect
• nx affected -t integration-test --parallel=3 --coverage.enabled
• nx affected -t unit-test --parallel=3 --coverage.enabled
• nx affected:lint --parallel=3
• nx affected:build --parallel=3

---

Sent with 💌 from NxCloud.

[BioPhoton]

Could that be a linting rule?

[BioPhoton]

Nice improvmenet!

[matejchalk]

@BioPhoton

Could that be a linting rule?

In general, lots of things could be linting rules. The more practical question is: Are there any linting rules available in the ecosystem? If not, we would have to implement that lint rule ourselves, in which case the cost-benefit ratio becomes highly questionable.

The current @code-pushup/eslint-config contains all the available rules I could find which I thought were beneficial. It's possible I missed something, of course. But mostly I would say that if it hasn't been added already, there's good chance it's because it doesn't exist or I didn't think it was beneficial (an inaccurate linting rule is worse than no linting rule, IMO).

Also, keep in mind that lint rules should be something that's universally a good thing. When it comes to practices that are good in some cases but in other's it's pointless or even counter-productive, then it's very difficult to automate accurately with a lint rule.

Regarding your specific requests:

• a rule to enforce .toEqual<T>(...) instead of untyped .toEqual(...):
  • Is it available? - Well, it would have to be specific to Vitest, so the place to look is eslint-plugin-vitest. I don't see any such rule there (I don't think any of their rules are TS-specific, actually).
  • Is it universal? - I'm not sure. The typed toEqual is mostly beneficial because of autocomplete, but the correctness checking is already take care of by the runtime assertion.
• a rule to enforce const x: T = ... instead of const x = ... satisfies T:
  • Is it available? - Since it's a TypeScript feature, the place to look is typescript-eslint. I can't see any rules regarding satisfies usage at all (could be because it's still a fairly new feature 🤷‍♂️).
  • Is it universal? - Potentially. The reason satisfies exists is to be able to do const x: T1 = ... satisfies T2, but I can't think of a practical use case for needing to do const x = ... satisfies T.

So in both cases, we would have to implement our own lint rule. I don't think either are important enough to prioritize such work though.