`Eval`ed UserInvocationStack is sometimes off for projects using Typescript 5

[AtofStryker]

Current behavior

Currently, when a user is running cypress commands that are wrapped inside serializable closures that throw errors, the stack trace line/column is slightly off when running typescript 5 projects. This can be seen inside our @packages/app tests when running stack trace validation when validating cy.intercept() stack errors inside reporter.command_errors.cy.ts

in cypress command log (typescript 5)

stack trace when opened in IDE (slight mismatch) (typescript 5)

This was realized when we updated the monorepo to typescript 5. see https://github.com/cypress-io/cypress/pull/29568/files#r1613972217

Desired behavior

The code snippet in the command log should match the stack trace that is visited to the user's IDE

in cypress command log (typescript 4)

stack trace when opened in IDE (slight mismatch) (typescript 4)

Test code to reproduce

see @packages/app tests when running stack trace validation when validating cy.intercept() stack errors inside reporter.command_errors.cy.ts

Cypress Version

13.10.0

Node version

v18.17.1

Operating System

macOS 14.3

Debug Logs

No response

Other

No response

[cypress-app-bot]

This issue has not had any activity in 180 days. Cypress evolves quickly and the reported behavior should be tested on the latest version of Cypress to verify the behavior is still occurring. It will be closed in 14 days if no updates are provided.

[ryanthemanuel]

This issue appears to happen because typescript 5 now appears to be inlining sourcemaps in its output. This creates an intermediate file that our userInvocationStack is pointing to.

For example if you have a test with source:

/// <reference types="cypress" />

interface Todo {
  title: string
  completed: boolean
}

function validateTodoList(selector: string, length: number) {
  cy.get(selector).should('have.length', length)
}

// Welcome to Cypress!
//
// This spec file contains a variety of sample tests
// for a todo list app that are designed to demonstrate
// the power of writing tests in Cypress.
//
// To learn more about how Cypress works and
// what makes it such an awesome testing tool,
// please read our getting started guide:
// https://on.cypress.io/introduction-to-cypress

describe('example to-do app', () => {
  beforeEach(() => {
    // Cypress starts out with a blank slate for each test
    // so we must tell it to visit our website with the `cy.visit()` command.
    // Since we want to visit the same URL at the start of all our tests,
    // we include it in our beforeEach function so that it runs before each test
    cy.visit('https://example.cypress.io/todo')
  })

  it('displays two todo items by default', () => {
    // We use the `cy.get()` command to get all elements that match the selector.
    // Then, we use `should` to assert that there are two matched items,
    // which are the two default items.
    validateTodoList('have.length', 1)

And this fails, we end up with a code frame that strips out all of the typescript type stuff:

This appears to be resolved if you set the typescript config to have sourceMap set to true. Ever since 13.12.0 we use that config to disable inline sourcemaps: https://github.com/cypress-io/cypress/blob/develop/npm/webpack-batteries-included-preprocessor/index.js#L40-L44

It's possible, we may need to revisit the sourcemaps properties and possibly default them differently between typescript 4 and 5.

[ryanthemanuel]

The original implementation of TypeScript patching occurred here: cypress-io/cypress-webpack-preprocessor#92

We should follow that logic to always set sourceMaps to true and inlineSourceMaps and inlineSources to false in our preprocessor.

[AtofStryker]

I have a PR out that is going to fix this issue in @cypress/webpack-batteries-included-preprocessor. Ideally, we should be taking the users tsconfig.json and piping all the compiler options into ts-loader, but we are currently only setting the sourceMap, inlineSourceMap, inlineSources, and downlevelIteration options. Since passing the the whole compiler options for this fix could be more disruptive (i.e. default module resolutions not being compatible with the config or other options, which we are seeing in our own projects), I think for now we just override and pass those 4 options and in Cypress 15 add the whole config to compilerOptions.

[cypress-bot]

Released in 14.2.1.

This comment thread has been locked. If you are still experiencing this issue after upgrading to
Cypress v14.2.1, please open a new issue.