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 #62715

Run Properties:   Passed #62715  •  e458cbcf21: Merge branch 'release/15.0.0' into feat/wbip_full_resolve_ts_config

Project	cypress
Branch Review	feat/wbip_full_resolve_ts_config
Run status	Passed #62715
Run duration	20m 17s
Commit	e458cbcf21: Merge branch 'release/15.0.0' into feat/wbip_full_resolve_ts_config
Committer	Jennifer Shehane
View all properties for this run ↗︎

---

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

UI Coverage  62.34%
Untested elements	27
Tested elements	48

Accessibility  96.16%
Failed rules	0 critical   4 serious   1 moderate   0 minor
Failed elements	119

[jennifer-shehane]

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

[jennifer-shehane]

Tested the situation before and it works more as expected. Tested some other situations - that the tsconfig is being read it properly with it preferring the cypress dir tsconfig.