Yicong-Huang opened a new pull request, #4862:
URL: https://github.com/apache/texera/pull/4862

   ### What changes were proposed in this PR?
   
   Step 1 of the Karma → Vitest migration tracked in #4861. This PR is 
**scaffolding only** — it switches the test runner wiring but intentionally 
leaves the spec files alone. The mechanical Jasmine → Vitest sweep lands in 
follow-ups so each diff stays reviewable.
   
   **Build target:**
   - `frontend/angular.json` — `test` target now uses 
`@angular/build:unit-test` with `runner: vitest`, points at `vitest.config.ts` 
via `runnerConfig`, reuses `gui:build` for app compilation.
   
   **New files:**
   - `frontend/vitest.config.ts` — enables `globals: true` so existing 
Jasmine-style specs keep using bare `describe/it/expect` without a per-file 
import sweep.
   - `frontend/src/vitest-globals.d.ts` — triple-slash reference to 
`vitest/globals` types. Needed because the parent `tsconfig.json` pins 
`typeRoots: ["node_modules/@types"]`, so listing `vitest/globals` in `types: 
[...]` doesn't resolve.
   
   **Removed:**
   - `frontend/karma.conf.js`, `frontend/src/test.ts` (the unit-test builder 
auto-generates TestBed init).
   - Karma + Jasmine deps from `package.json`: `karma`, 
`karma-chrome-launcher`, `karma-coverage`, `karma-jasmine`, `jasmine-core`, 
`@types/jasmine`, `@types/karma-coverage`.
   
   **Added:**
   - `[email protected]` (matches `@angular/build@21`'s peer range), `jsdom` 
(default test environment).
   
   **CI:**
   - `.github/workflows/build.yml` — frontend test invocation switches from 
`--code-coverage` (Karma builder flag) to `--coverage 
--coverage-reporters=lcovonly` (unit-test builder flags). Coverage output stays 
at `frontend/coverage/lcov.info`, so the Codecov upload glob is unchanged.
   
   ### What's intentionally NOT in this PR
   
   The 73 `*.spec.ts` files contain ~300 Jasmine-only patterns that don't 
compile under Vitest:
   
   | Pattern | Count | Vitest equivalent |
   |---|---:|---|
   | `toBeTrue()` / `toBeFalse()` | 72 | `toBe(true)` / `toBe(false)` |
   | `jasmine.createSpy / createSpyObj / any / objectContaining / Spy` | 98 | 
`vi.fn()` / object literal of `vi.fn()`s / `expect.any` / 
`expect.objectContaining` / `Mock` |
   | `.and.returnValue / callThrough / callFake / throwError` | 136 | 
`.mockReturnValue / (default) / .mockImplementation / 
.mockImplementation(throw)` |
   
   These sweeps are mechanical but voluminous; landing them here would push the 
PR over 1k lines of spec churn on top of the runner switch. Splitting keeps 
each PR focused.
   
   ### Any related issues, documentation, discussions?
   
   - Tracking issue: #4861
   - Supersedes the closed Jest attempt: #2995
   - Reasoning behind picking Vitest over Jest is captured in the issue body.
   
   ### How was this PR tested?
   
   Locally: `yarn install` resolves, `yarn ng test --watch=false` invokes the 
unit-test builder, builds the app, and reaches the spec compile stage where the 
expected Jasmine-only matcher errors surface (which is the work to be done in 
follow-ups).
   
   CI on this PR is **expected to fail** the \`Run frontend unit tests\` step 
until the mechanical sweep PRs land — opening as **draft** for that reason.
   
   ### Was this PR authored or co-authored using generative AI tooling?
   
   Generated-by: Claude Opus 4.7 (1M context)


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to