test(signals): update signal test to use vitest expectTypeOf

[santoshyadavdev]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/ngrx/platform/blob/main/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Documentation has been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[x] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

Closes #

What is the new behavior?

uses expectTypeOf for type testing, this closed #4935 partially

Does this PR introduce a breaking change?

[ ] Yes
[ ] No

Other information

[netlify]

✅ Deploy Preview for ngrx-io ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	3ff684b
🔍 Latest deploy log	https://app.netlify.com/projects/ngrx-io/deploys/69d3182d5c248d0008076900
😎 Deploy Preview	https://deploy-preview-5127--ngrx-io.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[rainerhahnekamp]

@santoshyadavdev. Looks reasonable to me at first sight. Still have to check it thoroughly, but it seems we will settle down with a combination of @ts-expect-error and Vitest type assertions?

[santoshyadavdev]

@santoshyadavdev. Looks reasonable to me at first sight. Still have to check it thoroughly, but it seems we will settle down with a combination of @ts-expect-error and Vitest type assertions?

Yes you are right, I will fix some pending code and linter soon

[mrazauskas]

Do I get it right that pnpm exec nx test signals should run the updated tests? Hm.. I tried adding obviously failing line (like const a: number = "abc") to modules/signals/spec/types/signal-state.types.spec.ts. Running the command reports all tests passing. Or did I misunderstood something?

@rainerhahnekamp Would be be still interested to check out TSTyche? (Based on #4935 (comment)). I could put together a similar PR. One of the advantages, there would be no need for @ts-expect-error directives, that cast too wide a net (in type testing context). Because any errors in the following line are suppressed.

[rainerhahnekamp]

A quick update from my side. I'd like to go through each test manually first because these are our lifesavers. I don't expect any issues, but I want to be 100% safe.

[timdeschryver]

This looks great, thanks @santoshyadavdev !
I left some comments with the differences between the old and new tests.

@rainerhahnekamp fyi, I wasn't aware of it, but the @ts-expect-error messages are not tested. This isn't blocking for me, but on the other hand this might give false confidence in the tests. That's why I'm fine with removing the message in these test cases.

[rainerhahnekamp]

@timdeschryver

I wasn't aware of it, but the @ts-expect-error messages are not tested. This isn't blocking for me,

I was aware. @mrazauskas pointed that out in his PR's description #5128 (comment). It isn't a blocker for me either and I am fine if we remove the messages to avoid misunderstandings.