fix(phoenix-ng): scope Jest and Cypress TS types to restore VS Code IntelliSense

[XPE-7]

Restore reliable Jest IntelliSense in VS Code by scoping TypeScript types for Jest and Cypress so their globals no longer collide.

Closes #722

---

Background

In VS Code, autocomplete and types for Jest matchers (e.g., toBeTruthy, toEqual) were missing in unit tests. The cause was a type collision: both Jest and Cypress define a global expect, and without scoping, Cypress/Chai typings can mask Jest matchers in editor tooling. Test execution was unaffected; this was a developer-experience issue.

---

What’s changed

• Added a Cypress-only TypeScript config to scope Cypress types to e2e and support files:
  • packages/phoenix-ng/projects/phoenix-app/cypress/tsconfig.json
• Updated the Jest spec TypeScript config to avoid overlap and support common test naming:
  • packages/phoenix-ng/tsconfig.spec.json
    • Added .test.ts to the include patterns
    • Excluded projects/phoenix-app/cypress from the Jest TS context

---

Why this approach

• Keeps each test framework’s typings where they belong:
  • Jest matchers are available in unit tests
  • Cypress/Chai chainables are available in e2e tests
• Minimal, targeted change with no runtime impact
• Scales well in monorepos and multi-test setups

---

Verification

• Restarted the TypeScript server in VS Code (Status Bar → “TypeScript x.x.x” → Restart TS Server)
• Confirmed:
  • Unit tests (.spec.ts / .test.ts under phoenix-ng/src): Jest matchers autocomplete and type-check correctly
  • Cypress tests (under projects/phoenix-app/cypress): Cypress/Chai chainables are available
• Local test run:
  • Test Suites: 3 skipped, 56 passed, 56 of 59 total
  • Tests: 7 skipped, 176 passed, 183 total
  • Snapshots: 0 total

---

Impact

• Developer experience: Restores Jest IntelliSense and type safety in unit tests
• No changes to application code, build, or test execution
• E2E authoring remains intact with proper Cypress typings

---

[EdwardMoyse]

Amazing! Thank you so much @XPE-7

[XPE-7]

Glad I could help. Let me know if there are any follow-ups or areas where I can contribute further.

[EdwardMoyse]

Well, actually the smoke test seems to have failed: https://github.com/HSF/phoenix/actions/runs/19465423744/job/55700828967

If you could have a look at that that would be great. And I'm also struggling to find time to look into the problem with #735, so any help with that would be much appreciated.

[XPE-7]

Thanks for the update, Edward. I’ll take a look at the smoke-test failure and try to understand what went wrong there.
I’ll also go through PR #735 and see what’s causing the test issues.
I’ll update you once I’ve got some findings.

[XPE-7]

@EdwardMoyse i have solved the smoke test issue you can verify and merge it here #737
and regarding #735, i am already into it and will open a PR shortly

[EdwardMoyse]

Hmm. Does this really work? I was just looking at atlas.component.test.ts and I see e.g.

So it seems like it is still mixing up cypress and jest... I restated the TS server and VSCode itself to be sure.

[XPE-7]

I checked atlas.component.test.ts locally and it’s currently being picked up by packages/phoenix-ng/tsconfig.json, not a Jest-specific tsconfig. Because of that, it can still see Cypress/Chai globals, which is why expect is resolving to Chai there even after a TS server restart.

The scoping change improved isolation overall, but this file isn’t actually associated with the Jest test config yet, so it’s effectively falling back to the main library project.

If we want to fully clean this up, the next step would likely be to either move these tests under a Jest-scoped config or introduce a dedicated test tsconfig for phoenix-ng so they don’t see Cypress types at all. Happy to help with that if you think it’s worth tightening further.