feat: allow for @cypress/webpack-batteries-included-preprocessor to fully resolve the tsconfig.json for compilerOptions in ts-loader (v15)

[AtofStryker]

fully resolves the user tsconfig compiler options instead of trying to infer the tsconfig.json implicitly

• Closes ts-loader in @cypress/webpack-batteries-included-preprocessor should respect all user compiler options #31282

Additional details

Passes in the discovered user's tsconfig.json compilerOptions from the cypress/ directory into ts-loader. This change is intended to give users more power of the cypress webpack preprocessor.

This is being flagged as a feature here, but is considered disruptive as it means users need to fully specify their tsconfig.json compatibility to work correctly with Cypress. This can be seen with the moduleResolution: "node" updates in @cypress/webpack-dev-server and @cypress/vite-dev-server as the default resolution is "classic" and doesn't work with "resolveJsonModule". For most user's, this should be a passive change.

Regardless of passed in options, sourceMap=true is always overridden in the @cypress/webpack-preprocessor since Cypress needs source maps to deliver accurate snapshots and code frames.

Steps to test

use the pre-release binaries in 484c2eb#comments to run against some sample tsconfigs in the cypress/ directory of your project. If you run DEBUG=cypress:webpack-batteries-included-preprocessor npx cypress open you should now be able to see which tsconfig compilerOptions are being passed in.

How has the user experience changed?

Previously, @cypress/webpack-batteries-included-preprocessor would use ts-loader without specifying any type of compilerOptions, which will try to imply the compilerOptions from the relatively resolved tsconfig.json of the file/process, which may not be correct as we want to use the defined tsconfig.json in the cypress/ directory, or project root if one does not exist.

With this change, we are now make sure to use the user's defined tsconfig.json compilerOptions to process the file.

Additionally, if processing TypeScript files without a tsconfig.json in the project root or in the cypress directory, the preprocessor now throws an error. This is to improve the error thrown in #18938, but does not completely close the issue

PR Tasks

• Have tests been added/updated?
• Has a PR for user-facing changes been opened in cypress-documentation? chore: update typescript docs to tsx cypress-documentation#6155
• Have API changes been updated in the type definitions?

[cypress]

cypress    Run #62346

Run Properties:   Failed #62346  •  4e6f1170d9: empty commit to run ci

Project	cypress
Branch Review	feat/wbip_full_resolve_ts_config
Run status	Failed #62346
Run duration	19m 25s
Commit	4e6f1170d9: empty commit to run ci
Committer	Bill Glesias
View all properties for this run ↗︎

---

Test results
Failures	2
Flaky	2
Pending	27
Skipped	0
Passing	746
View all changes introduced in this branch ↗︎

UI Coverage  62.34%
Untested elements	27
Tested elements	48

Accessibility  96.15%
Failed rules	0 critical   4 serious   1 moderate   0 minor
Failed elements	151

---

Tests for review

  cypress\e2e\studio\studio.cy.ts • 2 failed tests • app-e2e

View Output

Test		Artifacts
Cypress Studio > cloud studio > opens studio panel to new test when clicking on studio button (from the app) next to url		Test Replay Screenshots
Cypress Studio > cloud studio > opens a cloud studio session with AI enabled		Test Replay Screenshots

  cypress\e2e\runner\ct-framework-errors.cy.ts • 1 flaky test • app-e2e

View Output

Test		Artifacts
Next.js > error conditions		Test Replay Screenshots

  cypress\e2e\studio\studio.cy.ts • 1 flaky test • app-e2e

View Output

Test		Artifacts
Cypress Studio > cloud studio > immediately loads the studio panel		Test Replay Screenshots

[jennifer-shehane]

I encountered an unusual error with a project with a ts file and no tsconfig that requires looking into. Slack thread