Component testing broken with NextJS 13.2.1

[jamesopti]

Current behavior

Component tests run fine on NextJS v13.1.1, but fail to compile on v13.2.1

The error received is unable to find module, where the module resolution relies on the tsconfig basePath setting in /cypress/tsconfig.json

Component test cypress config settings:

component: {
    devServer: {
      framework: 'next',
      bundler: 'webpack',
    },
}

Desired behavior

Component tests should compile and run using the tsconfig.json settings.

Possibly related NextJS change/update: vercel/next.js#45455

Test code to reproduce

Run any component test that uses a custom cypress tsconfig with NextJS v13.2.1

Cypress Version

latest

Node version

v16.3

Operating System

MacOSX And Github Actions Linux

Debug Logs

No response

Other

No response

[jamesopti]

This issue looks to be the same: #25943

[lmiller1990]

Hey team! Please add your planning poker estimate with Zenhub @astone123 @marktnoonan @mike-plummer @warrensplayer @ZachJW34

[lmiller1990]

Thanks for the bug report (and tracking down the actual change, by the looks of it!). We will look at this in the next week or so.

[ZachJW34]

The Next update added a new property to the getBaseWebpackConfig that we utilize for sourcing the Next config. The new jsconfig option sets up the ts aliases.

They export a loadProjectInfo function that grabs the {ts,js}.config.json we could utilize, or use the load-jsconfig.ts directly

[OleksiiKachan]

can we have a release with this?

[astone123]

@OleksiiKachan this will be included in release 12.8.0 which should be released today

[franzwarning]

Just updated to 12.8 and I'm getting an error that cypress can't resolve my modules that I import w/ absolute paths:

Module not found: Can't resolve 'src/utils/date'

This was working before our Next 13.2 update... any ideas?

[astone123]

@franzwarning are you able to share your ts/js config?

[franzwarning]

@franzwarning are you able to share your ts/js config?

{
  "compilerOptions": {
    "target": "es6",
    "lib": [
      "dom",
      "dom.iterable",
      "esnext"
    ],
    "allowJs": true,
    "skipLibCheck": true,
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "noFallthroughCasesInSwitch": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": true,
    "jsx": "preserve",
    "incremental": true,
    "baseUrl": ".",
    "plugins": [
      {
        "name": "next"
      }
    ]
  },
  "include": [
    "**/*.ts",
    "**/*.tsx",
    ".next/types/**/*.ts"
  ],
  "exclude": [
    "node_modules"
  ]
}

[franzwarning]

@astone123 fixed by adding:

"paths": {
      "src/*": [
        "src/*"
      ],
      "mocks/*": [
        "mocks/*"
      ],
      "public/*": [
        "public/*"
      ],
    },

but I shouldn't really have to do that right? idk y'all know better than me!

[astone123]

@franzwarning my understanding is that you should not have to add the paths to your config, the modules should be resolved using baseUrl. Can you help me understand when this stopped working?

Next 13.2 + Cypress 12.7 and previous ✅ ?
and
Next 13.2 + Cypress 12.8 ❌ ?

[franzwarning]

✅ Next 13.1.6 Cypress 12.7
❌ Next 13.2.x Cypress 12.7 (when I started following this issue) (I forget what broke the first time -- might have been the same issue?)
❌ Next. 13.2.x Cypress 12.8

Hope that helps.

[OleksiiKachan]

I had "*" alias. in addition to ["src/*"] had to add node_modules
so my alias looks like "*": ["src/*", "node_modules"]

"next": "^13.2.4",
"cypress": "^12.8.0",

now all works for me

[jamesopti]

I can confirm this is still broken for me too. the baseUrl setting is not being respected.

tsconfig.json:

{
  "compilerOptions": {
    "baseUrl": "./src",
    "paths": {
      "publicImages/*": ["../public/images/*"]
    },
    "target": "es2015",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "strict": false,
    "forceConsistentCasingInFileNames": true,
    "noEmit": true,
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "sourceMap": true,
    "isolatedModules": true,
    "noImplicitReturns": true,
    "importHelpers": true,
    "strictNullChecks": true,
    "suppressImplicitAnyIndexErrors": true,
    "noUnusedLocals": false,
    "allowSyntheticDefaultImports": true,
    "downlevelIteration": true,
    "strictBindCallApply": true,
    "jsx": "preserve",
    "incremental": true
  },
  "exclude": ["node_modules", "cypress", "./cypress.config.ts"],
  "include": [
    "next-env.d.ts",
    "fontawesome.d.ts",
    "**/*.ts",
    "**/*.tsx",
    "src/test/jest-setup.ts",
    "jest.config.ts"
  ]
}

[lmiller1990]

Looks like our fix didn't work. We will look into this now.

[yosi1314]

The version update or the paths workaround didnt work for me. Any updates?

**Edit - Adding NODE_PATH=src solved it for me

[lmiller1990]

We will be looking into this in the next week or two! Sorry about the wait.

[jamesopti]

We will be looking into this in the next week or two! Sorry about the wait.

This doesn't inspire a lot of confidence in the Component testing product 😕

[lmiller1990]

I'm sorry this isn't working for you right now. We can definitely add a regression test as part of this fix, so it is less likely to happen in the future. We will take a look next week.

If you'd like to take a stab at fixing it before then, I can help with reviewing and releasing the fix.

The Next.js specific code is in this file: https://github.com/cypress-io/cypress/blob/develop/npm/webpack-dev-server/src/helpers/nextHandler.ts. Next.js does not expose a public API for their configuration, which is why it can break in a minor version.

Any ideas on the correct fix? Should we just add NODE_PATH=<your_base_url>? Does the NODE_PATH fix work for you @jamesopti?

[lmiller1990]

I am working on this. It works in Next 13.0.0 but not in 13.2.1. I will debug more, but I think the issue title is a bit of a red herring - I think the breakage was earlier.

✅ 13.1.4
✅ 13.1.5
✅ 13.1.6
✅ 13.1.7-canary.0
✅ 13.1.7-canary.1
✅ 13.1.7-canary.2
✅ 13.1.7-canary.3
✅ 13.1.7-canary.4
✅ 13.1.7-canary.6
❌ 13.1.7-canary.7
...
❌ next@13.1.7-canary.21
❌ 13.1.7-canary.32
❌ 13.2.0

[jamesopti]

@lmiller1990 Thanks for the update and sorry for my slightly snarky response earlier.

I didn't realize this was powered by an unsupported NextJS API, so totally understand the challenge. Next is a great platform but their support for testing & CI leaves something to be desired.

I'm happy to test a NODE_PATH fix if thats a workaround!

[lmiller1990]

@jamesopti all good, no-one likes it when their thing randomly breaks. I updated my post above - I found the issue was introduced in 13.1.7-canary.7. This greatly minimizes the surface area, I am sure we can fix this very soon 👍

You could use the work around for the next week or so, I'm fairly confident we will ship the fix in the next Cypress version.

[lmiller1990]

Diff... vercel/next.js@v13.1.7-canary.6...v13.1.7-canary.7. Lots of files but mostly static content. Some interesting parts:

• vercel/next.js@v13.1.7-canary.6...v13.1.7-canary.7#diff-5f441142eb8ba9bcba515aa36fbc420a113307bd191e54a4e9e6c43529fc2613R587 (references resolvedBaseUrl)

Here we go - this grabs the baseUrl I am not sure why we don't get this for free, since we just use the same webpack config as Next.js, but I think we can find a fix for this:

This line was added in Next.js 12.x, but it wasn't actually added to the webpackBaseConfig via spreading ...info until 13.1.7-canary.7. here. That's why it broke - I wonder if we load the webpack config in a different fashion, prior to ...info getting spread, updating the baseUrl.

[lmiller1990]

Hi friends, I fixed it! #26399 /cc @jamesopti @OleksiiKachan @yosi1314. You can test it out using a pre-release binary: 6a37c4a#comments

Next release is tomorrow, I'll get some 👀 and ✅ so this can make it in 😎

[jamesopti]

Thanks for the fix @lmiller1990 - Looks like a release didn't happen last Monday.

Can we expect one today?

[mike-plummer]

@jamesopti Sorry about the miscommunication, @lmiller1990 was off by one week on our release cadence (and he's in Australia so all the days are off-by-one). Our next release is planned for tomorrow (Tuesday).

[lmiller1990]

@jamesopti did you try the pre-release? You can start using this right now: bf7771f#comments and then upgrade to the mainline release when it comes out.

Those pre-release binaries expire eventually, but it's live for me right now.

[jamesopti]

@jamesopti did you try the pre-release? You can start using this right now: bf7771f#comments and then upgrade to the mainline release when it comes out.

Those pre-release binaries expire eventually, but it's live for me right now.

Thanks for pointing out how easy it is to test with these!

I confirmed that this release passes all tests in our suite. Will wait for tomorrows deploy.

[dbrxnds]

When exactly can we expect this release?

[marktnoonan]

Sorry for the wait. We typically release every two weeks on a Tuesday, but it's possible to get off that cadence every now and then, as we are here.

This is where the pre-release binaries come in handy. They last for 30 days. Please don't be blocked on your side waiting for the official release, if you need to start using this now, you can switch to the binary that has the fix now (#25951 (comment)), and then switch back to the new version of Cypress when it comes out.

[cypress-bot]

Released in 12.10.0.

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