Change in test file crashes component tests after upgrading to Mac

[will-weiss]

Current behavior

Hello! Thanks in advance for your assistance with this issue.

After I updated to Mac Ventura, I started seeing that any change to my test file crashes my open component tests as can be seen in the attached video. Changes to the non-test code does not crash the component tests.

demo.mov

[Stack trace](http://localhost:50705/__/#)
Error: EPERM: operation not permitted, utime '/Users/willweiss/Library/Caches/Cypress/10.11.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/@cypress/webpack-dev-server/dist/browser.js'
    at utimesSync (node:fs:2025:3)
    at EventEmitter.CypressCTWebpackPlugin.onSpecsChange (/Users/willweiss/Library/Caches/Cypress/10.11.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/@cypress/webpack-dev-server/dist/CypressCTWebpackPlugin.js:64:13)
    at EventEmitter.emit (node:events:513:28)
    at EventEmitter.emit (node:domain:489:12)
    at EventEmitter. (/Users/willweiss/Library/Caches/Cypress/10.11.0/Cypress.app/Contents/Resources/app/packages/server/lib/plugins/child/dev-server.js:9:21)
    at EventEmitter.emit (node:events:513:28)
    at EventEmitter.emit (node:domain:489:12)
    at process. (/Users/willweiss/Library/Caches/Cypress/10.11.0/Cypress.app/Contents/Resources/app/packages/server/lib/plugins/util.js:33:26)
    at process.emit (node:events:513:28)
    at process.emit (node:domain:489:12)
    at process.emit.sharedData.processEmitHook.installedValue [as emit] (/Users/willweiss/Library/Caches/Cypress/10.11.0/Cypress.app/Contents/Resources/app/node_modules/@cspotcode/source-map-support/source-map-support.js:745:40)
    at emit (node:internal/child_process:939:14)
    at processTicksAndRejections (node:internal/process/task_queues:84:21)
SpecRunner
Passed:
4
Failed:
--
Pending:
--
[EnsureFeatureSwitchesFetched.cyC.test.tsx](http://localhost:50705/__/#)344ms
EnsureFeatureSwitchesFetched
blocks rendering children until feature switches are fetched from the API when switch is onpassed
blocks rendering children until feature switches are fetched from the API when switch is offpassed
uses feature switches fetched from NativeApp if available and doesn't call the API if all necessary switches are presentpassed
still makes a request to the API if the NativeApp doesn't have all the feature switches we needpassed

ChromeChrome 106

360x760
(92%)

Desired behavior

In this situation, cypress should stay open after updating my test file

Test code to reproduce

Tests are run via

TZ=America/New_York yarn cypress run --component --browser chrome --config watchForFileChanges=false

on version 10.11.0.

with a cypress.config.ts file that looks like this

export default defineConfig({
  projectId: ...,
  downloadsFolder: "src/test/cypress/downloads",
  fixturesFolder: "src/test/cypress/fixtures",
  screenshotsFolder: "src/test/cypress/screenshots",
  videosFolder: "src/test/cypress/videos",
  defaultCommandTimeout: 10000,
  watchForFileChanges: false,
  viewportWidth: 360,
  viewportHeight: 760,
  retries: {
    runMode: 2,
    openMode: 0
  },
  video: false,
  chromeWebSecurity: false,
  e2e: {
    baseUrl: "https://parent-android-web.classdojo.test:4002",
    setupNodeEvents(on, config) {
      on("file:preprocessor", cypressEsbuildPreprocessor({}));
      return config
    },
    specPattern: "src//**/*.cyI.test.{ts,tsx}",
    supportFile: "src/test/cypress/support/e2e.ts",
  },
  component: {
    setupNodeEvents(on, config) { },
    specPattern: "src/**/*.cyC.test.{ts,tsx}",
    supportFile: "src/test/cypress/support/component.js",
    devServer: {
      framework: "next",
      bundler: "webpack",
    },
  },
});


### Cypress Version

10.11.0

### Node version

v16.17.0

### Operating System

macOS

### Debug Logs

_No response_

### Other

_No response_

[marktnoonan]

Hi @will-weiss, we will try to reproduce this on our side.

In the mean time, a bit of a guess: in my personal experience with Mac upgrades recently, I have seen file and folder permissions get weirdly messed up. Since you are hitting Error: EPERM: operation not permitted I wonder if that could be related.

Curious if running cypress cache clear https://docs.cypress.io/guides/guides/command-line#cypress-cache-clear and peforming a fresh install of Cypress would behave differently for you, if you want to try it.

[TapaiBalazs]

Hi @marktnoonan

I encountered the same issue. I did what you suggested and ran the following commands:
cypress cache clear and then installing it again with cypress install && cypress verify

I get the same error:

Error: EPERM: operation not permitted, utime '/Users/btapai/Library/Caches/Cypress/10.11.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/@cypress/webpack-dev-server/dist/browser.js'
    at utimesSync (node:fs:1975:3)

I checked the premissions for that exact file running ls -la:

-rw-r--r--  1 btapai  staff  89 Oct 25 01:38 /Users/btapai/Library/Caches/Cypress/10.11.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/@cypress/webpack-dev-server/dist/browser.js

Trying to change the permissions of that file does not work either. I tried it with sudo as well doing chmod 777 on it, but:

chmod: Unable to change file mode on /Users/btapai/Library/Caches/Cypress/10.11.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/@cypress/webpack-dev-server/dist/browser.js: Operation not permitted

When I check the permissions in Finder however, the permissions are set to Read and Write on the file.

[amehta265]

@will-weiss Thank you for providing the update and error logs.
I have upgraded to MacOS Ventura and have tried to reproduce this issue on my end. Unfortunately all the tests and hot reloading works just as expected. This does not mean that your issue is not happening, but just means that there may be unaccounted factors playing a role in producing this error.
Would you be able to provide a Short, Self Contained, Correct, Example in a shared repository so that I can reproduce this error on my end. This would significantly help debugging and finding a solution to this issue.

[TapaiBalazs]

Hi @amehta265

I tried to create a small reproduction, but if I create a new project with the same setup (for me it is an NX angular project with component testing enabled), then I cannot reproduce the issue, so I started debugging the differences.

For reference:
old repository === the one that encounters the issue almost every time when a test file changes
new repository === the one I created a few hours ago with the same setup

1. The utimesSync call comes from the CypressCTWebpackPlugin.js file from the onSpecsChange method. (Lines 63-64 in the /Users/btapai/Library/Caches/Cypress/10.11.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/@cypress/webpack-dev-server/dist/ folder
2. In the new repository the dev-server:specs:changed event is only emitted once, and it happens before the CypressCTWebpackPlugin.js subscribes to it (before its .apply() method is called)
3. in the old repository it gets emitted every time a change occurs in a test file.
4. In the new repository when a test file changes the dev-server:compile:success gets emitted

Sadly I cannot share the old repository with you, since it is a private repository and the reproduction repository does not cause this error. :(

I do have a workaround for that repository, namely to manually comment out the utimesSync in the file that is in the /Users/btapai/Library/Caches/Cypress/10.11.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/@cypress/webpack-dev-server/dist/ but I don't really know what that would break in other repositories and tests.

[amehta265]

@TapaiBalazs Thank you for trying to make a reproduction and sharing the differences in the old and new repositories.
I am glad you have found a work around for now!
As mentioned before, it is difficult to resolve this problem permanently without a reproduction. However, based on your findings and differences, I will be looking into why utimeSync maybe causing your tests to fail.

[lmiller1990]

I wonder if you launch Cypress with sudo does it make a difference? Obviously not a real solution, but it would be one way to verify it's definitely a permissions issue.

We need utimeSync to force webpack to re-compile when a new spec file is added or removed. By commenting this out, you would need to restart Cypress every time you add a new spec (when using webpack dev server).

If someone who can reproduce this wanted to explore some other API to touch the browser.js file, that would be a good way to debug. I suspect the problem will happen regardless of how you touch that file, though, since it's a permissions issue (from what I can see).

In the meantime, I wonder if we should just add a try/catch to that part of the code, so at least Cypress won't crash. This might be a good enough fix until we can properly isolate the problem, WDYT @amehta265?

[TapaiBalazs]

@lmiller1990 Thank you for your input! Based on that I was able to create a reproduction:

See the video:
https://user-images.githubusercontent.com/13385210/199425420-1725de39-ba00-4c3d-8f4a-95adcd73e1c3.mov

Which I also uploaded to this reproduction repository: https://github.com/TapaiBalazs/cypress_24398_repro

Please let me know if I can help you further

---

So, in my opinion, there are two issues at play here:

1. In my old repository, if I change a line in a test file, it will trigger the listener for creating/deleting a new test file and crashes cypress every time I change a file.
2. MacOS Ventura might handle bundled files differently than previous versions of the os and forcing the dev server inside the Cypress.app with utimesSync might no longer be a viable option. 🤔

I wonder if you launch Cypress with sudo does it make a difference? Obviously not a real solution, but it would be one way to verify it's definitely a permissions issue.

When I run the command with sudo, the same issue happens, that's why I think the issue has something to do with the new MacOS version.

[amehta265]

@TapaiBalazs Thank you for providing a reproducible example.
After further investigation it seems as though this is a permissions issue.
As @lmiller1990 explained, when you create a new spec file, uTimesSync updates the timestamp for browser.js file thereby 'tricking' webpack to re-bundle - in the process adding the newly created spec file to the new bundled browser.js file.

The issue on my MacOS Ventura is that Visual Studio Code did not have full disk access. You can change this by going to: system settings - privacy and security - full disk access and toggling on access for visual studio code. I believe this gives Visual Studio access to write to files thereby allowing Cypress (while it is running on VSC) to update the timestamps for browser.js through uTimesSync

This is definitely not a permanent solution but is merely an explanation and a work around without having to manually comment out the code in your bundled files.

Let me know if this solution works for you.

[TapaiBalazs]

@amehta265 I use Webstorm, but I can confirm that when I added it to the full disk access list in the settings, the issue is not present anymore.

Although, I do wonder how good of an idea it is to give full disk access to an IDE. 🤔

[amehta265]

@TapaiBalazs I agree with you that giving full disk access to an IDE is definitely not a permanent solution and is merely a workaround. Cypress needs access to folders and files in this path /Users/btapai/Library/Caches/Cypress/10.11.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/@cypress/webpack-dev-server/dist/ in order to read and write to the Cypress files in cache. Providing full disk access allows Cypress to do this. Ideally Cypress would have access to all its downloaded binaries irrespective of the IDE being used.

We will definitely be looking into a more permanent solution but I'm glad we have a work around for now.

[TapaiBalazs]

@amehta265

Yes I understand, thank you very much for everything! :)

[croor005]

I wonder if you launch Cypress with sudo does it make a difference? Obviously not a real solution, but it would be one way to verify it's definitely a permissions issue.

We need utimeSync to force webpack to re-compile when a new spec file is added or removed. By commenting this out, you would need to restart Cypress every time you add a new spec (when using webpack dev server).

If someone who can reproduce this wanted to explore some other API to touch the browser.js file, that would be a good way to debug. I suspect the problem will happen regardless of how you touch that file, though, since it's a permissions issue (from what I can see).

In the meantime, I wonder if we should just add a try/catch to that part of the code, so at least Cypress won't crash. This might be a good enough fix until we can properly isolate the problem, WDYT @amehta265?

Running with sudo makes this go away

[lewishowles]

Just to add that in my case I'm running Cypress from my terminal, and running with sudo doesn't solve the problem. In addition to when creating a new spec file, this also happens almost every time an existing file is saved.

Providing my terminal with full disk access did solve the problem as mentioned.

However, it seems like trying again in 12.2, the error is caught and doesn't crash Cypress, but providing full disk access no longer resolves the issue, and the test window needs to be closed and opened again from the E2E / Component screen.

[Szymon-dziewonski]

@amehta265 thank you! after of couple of hours searching for issue and pulling my hair from head, your reply fixed my problem, appreciate that ! :) It was exactly like you wrote, after update to ventura I was missing permissions, giving full access to VSC fixed issue. However Im waiting for better solution :)

[lmiller1990]

Some debugging here: #24876 that should help, potentially same issue (both having permission issues on Ventura).

[lmiller1990]

I have this too, but it is not consistent. I got an error and I hit "try again" and it worked. ????

Anything in /Users/<user>/Library/Caches/Cypress/12.4.1/Cypress.app/Contents is readonly when I try to edit it, even if user, staff, and everyone has rw permissions (including editing with vi, nano, etc).

Only impacting webpack, since vite does not try to write to the file system. If we can remove https://github.com/cypress-io/cypress/blob/develop/npm/webpack-dev-server/src/CypressCTWebpackPlugin.ts#L113 we could avoid this all together. Without that line, new specs are not added to the webpack bundle according to https://github.com/cypress-io/cypress/blob/develop/npm/webpack-dev-server/src/CypressCTWebpackPlugin.ts#L95-L100. Worth seeing if we can "trick" webpack into re-bundling when a new spec file is added.

[lmiller1990]

@amehta265 thank you! after of couple of hours searching for issue and pulling my hair from head, your reply fixed my problem, appreciate that ! :) It was exactly like you wrote, after update to ventura I was missing permissions, giving full access to VSC fixed issue. However Im waiting for better solution :)

This is weird - why on earth would this fix it! Strange.

[marktnoonan]

@lmiller1990 If memory serves, when I had a similar issue after a (non-Ventura) upgrade, I found an ancestor folder that had readonly permissions that were inherited by folders that otherwise looked to have fine permissions, and things worked nomally after deleting that ancestor and re-installing (possibly /Library/Caches/Cypress? I don't remember). This was an issue nobody else seemed to have back then, I thought it was something specific about my situation and changes we were making to device management at the time.

[lmiller1990]

Update...

@astone123 reports:

okay, I'm able to write to /Users/adams/Library/Caches/Cypress/12.5.1/Cypress.app/Contents/Resources/app/packages/server/node_modules/@cypress/webpack-dev-server/dist/browser.js after I change "everyone" to read and write via Finder.
So -rw-r--r-- --> -rw-rw-rw-@

The @ symbol according to this which leads here...

Explains why this MacOS specific, but not why we cannot write there.

According to stack exchange:

And just in case if you want to remove those attribes, you can use xattr -c filename.ext or xattr -cr somefolder to do it recursively.

Maybe we can use this info somehow? We could detect the OS and make sure this file is writable (and add/remove/change the xattr correctly).

[lmiller1990]

 xattr /Users/<user>/Library/Caches/Cypress/12.5.1/Cypress.app/Contents/Resources/app/packages/server/node_modules/@cypress/webpack-dev-server/dist/browser.js
com.apple.lastuseddate#PS
com.apple.macl

com.apple.macl is explained here, related to permissions. This could be related.

The MACL attribute usually consists of a header value of 02 00 followed by a UUID corresponding to the application permitted to access the file. The UUID is unique for each system, user and application meaning that we can’t preempt what this value will be in advance.

I wonder if Cypress (and vi, etc) are not in this value (cannot preempt a unique uuid) so we cannot edit the file. It's still not clear why this only happens post-upgrade - tighting of security?

[astone123]

For anyone else who comes across this, the only way that I could get this to go away is by editing the permissions for /Users/<user>/Library/Caches/Cypress/<version>/Cypress.app/Contents/Resources/app/packages/server/node_modules/@cypress/webpack-dev-server/dist/browser.js via Finder. This is the file that we edit when the spec changes in order to force Webpack to re-compile.

It doesn't seem to matter what exactly I change, but in my case what I did was

1. Click the padlock icon in the bottom-right corner and authenticate
2. Change the group permission (second one down) from "Read only" to "Read & Write"
3. Then change the group permission back to "Read only"
4. Re-launch Cypress and make sure that the error isn't thrown when you edit your spec file

Like Lachlan said, you'll now see the permissions in terminal as -rw-r--r--@, the @ being some attributes that are Mac specific that must have been added when we were editing permissions via Finder. It seems like those attributes are what is allowing us to now write to browser.js and not throw the error, because the file permissions are exactly the same otherwise.

This is only a workaround until we can find a way to either stop editing this file or fix the permissions issue with the way that we package the application. Not sure why this is only happening on Ventura

[gearsdigital]

Not sure if it helps but I was able to finally solve this (absurdly annoying) issue by adding my Terminal and IDE (IntelliJ) to the "App Managemet" Setting which will enable these apps to update or delete other apps.

I added both apps because this is where I start my tests from.

Just to mention, I got this error almost every time I change code. Now it's working for hours since 👻

MacBook Pro
16", 2021
Ventura 13.2.1 (22D68)

Settings > Privacy & Security > App Management (Section Privacy)

[valscion]

I did a similar thing as @gearsdigital did. For me, it was the terminal that I had to add to the list of applications that can update or delete other applications:

Now the error went away.

My mac specs:

[gearsdigital]

Still working fine for me... Had the runner open almost the whole day and no issues so far.

[marktnoonan]

That would explain why I didn't have these issues recently, thanks for the report @gearsdigital - I recently got a new computer with Ventura. Somewhere in the flow of setting up I agreed these permissions, I just checked, and it's exactly as you said, terminal + IDE.

[gearsdigital]

Somewhere in the flow of setting up I agreed these permissions

@marktnoonan That is exactly what I did yesterday after my Terminal asked me for that very permisson – right after I started the cypress test runner.

But now I'm afraid to revoke this permssions just for verifying this issue because everything runs smoothly now 🙈

Anyhow, I just did that and fiddled around a bit and I can confirm that the issue is back after revoking those permissions. After regranting, the issue is gone again. So it's reproducible now I guess.

[valscion]

Yeah I think that what happens here is that the application that open the Cypress application needs to have the right to update or delete other applications because there is something inside the Cypress application files that need to be changed or looked at when component tests are running.

If the thing that is changing or is checked against would live outside of the Cypress.app directory, then this issue might not happen.

[lmiller1990]

I think we've got a fix, please wait a few days, @astone123 will post a PR.

[lmiller1990]

This fix is in Cypress 12.7 - let us know if you are still having issues.

[scebotari66]

I didn't use to have this issue, but I have encountered it after upgrading to 12.7.
Here is the full stack trace:

Error: ENOENT: no such file or directory, utime '/Users/serghei/Code/MyApp/support/component-index.html'
    at utimesSync (node:fs:2033:3)
    at EventEmitter.CypressCTWebpackPlugin.onSpecsChange (/Users/serghei/Library/Caches/Cypress/12.7.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/@cypress/webpack-dev-server/dist/CypressCTWebpackPlugin.js:70:13)
    at EventEmitter.emit (node:events:513:28)
    at EventEmitter.emit (node:domain:489:12)
    at EventEmitter. (/Users/serghei/Library/Caches/Cypress/12.7.0/Cypress.app/Contents/Resources/app/packages/server/lib/plugins/child/dev-server.js:9:21)
    at EventEmitter.emit (node:events:513:28)
    at EventEmitter.emit (node:domain:489:12)
    at process. (/Users/serghei/Library/Caches/Cypress/12.7.0/Cypress.app/Contents/Resources/app/packages/server/lib/plugins/util.js:33:22)
    at process.emit (node:events:513:28)
    at process.emit (node:domain:489:12)
    at process.emit.sharedData.processEmitHook.installedValue [as emit] (/Users/serghei/Library/Caches/Cypress/12.7.0/Cypress.app/Contents/Resources/app/node_modules/@cspotcode/source-map-support/source-map-support.js:745:40)
    at emit (node:internal/child_process:937:14)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)

component-index.html is set in component.indexHtmlFile.

Cypress starts ok, but crashes after I change some spec file.

[marktnoonan]

@scebotari66 thanks for this - taking a guess at a glance here, is the component.indexHtmlFile path set to something other than support/component-index.html?

Although initially that doesn't look it should be a problem 🤔

[scebotari66]

@marktnoonan, here is how it's set:

But as you have mentioned, this might not be the issue, since it works on Cypress start. It only crashes after I update a spec file.

[marktnoonan]

@scebotari66 could you share the absolute path to component-index.html? As much as you are comfortable. I wonder if there is a similar permissions issue to the one described here.

[scebotari66]

@marktnoonan, sure. It is /Users/serghei/Code/MyApp/cypress/support/component-index.html

[marktnoonan]

@scebotari66 thanks. If you remove the indexHtmlFile from the component config, what happens? It looks like it is in the default location already. Maybe I'm missing something.

I can see that the path which errors in your log (/Users/serghei/Code/MyApp/support/component-index.html) is missing the cypress folder. Some code changes were made in this area, it's possible you've hit an edge case where the componentIndex is defined in this way.

[scebotari66]

@marktnoonan, if I remove indexHtmlFile from config, I get the following error when a spec is executed:

 Error: Child compilation failed:
  Module not found: Error: Can't resolve '/Users/serghei/Code/MyApp/  cypress/cypress/support/component-index.html' in '/Users/serghei/Code/MyApp/cypress'
  ModuleNotFoundError: Module not found: Error: Can't resolve '/Users/serghei/Co  de/MyApp/cypress/cypress/support/component-index.html' in '/Users/  serghei/Code/MyApp/cypress'
      at /Users/serghei/Code/MyApp/node_modules/webpack/lib/Compilat  ion.js:2016:28
      at /Users/serghei/Code/MyApp/node_modules/webpack/lib/NormalMo  duleFactory.js:798:13
      at eval (eval at create (/Users/serghei/Code/MyApp/node_module  s/tapable/lib/HookCodeFactory.js:33:10), :10:1)
      at /Users/serghei/Code/MyApp/node_modules/webpack/lib/NormalMo  duleFactory.js:270:22
      at eval (eval at create (/Users/serghei/Code/MyApp/node_module  s/tapable/lib/HookCodeFactory.js:33:10), :9:1)
      at /Users/serghei/Code/MyApp/node_modules/webpack/lib/NormalMo  duleFactory.js:434:22
      at /Users/serghei/Code/MyApp/node_modules/webpack/lib/NormalMo  duleFactory.js:120:11
      at /Users/serghei/Code/MyApp/node_modules/webpack/lib/NormalMo  duleFactory.js:670:25
      at /Users/serghei/Code/MyApp/node_modules/webpack/lib/NormalMo  duleFactory.js:855:8
      at /Users/serghei/Code/MyApp/node_modules/webpack/lib/NormalMo  duleFactory.js:975:5
      at /Users/serghei/Code/MyApp/node_modules/neo-async/async.js:6  883:13
      at /Users/serghei/Code/MyApp/node_modules/webpack/lib/NormalMo  duleFactory.js:958:45
      at finishWithoutResolve (/Users/serghei/Code/MyApp/node_module  s/enhanced-resolve/lib/Resolver.js:312:11)
      at /Users/serghei/Code/MyApp/node_modules/enhanced-resolve/lib  /Resolver.js:386:15
      at /Users/serghei/Code/MyApp/node_modules/enhanced-resolve/lib  /Resolver.js:435:5
      at eval (eval at create (/Users/serghei/Code/MyApp/node_module  s/tapable/lib/HookCodeFactory.js:33:10), :16:1)
      at /Users/serghei/Code/MyApp/node_modules/enhanced-resolve/lib  /Resolver.js:435:5
      at eval (eval at create (/Users/serghei/Code/MyApp/node_module  s/tapable/lib/HookCodeFactory.js:33:10), :27:1)
      at /Users/serghei/Code/MyApp/node_modules/enhanced-resolve/lib  /DescriptionFilePlugin.js:87:43
      at /Users/serghei/Code/MyApp/node_modules/enhanced-resolve/lib  /Resolver.js:435:5
      at eval (eval at create (/Users/serghei/Code/MyApp/node_module  s/tapable/lib/HookCodeFactory.js:33:10), :16:1)
      at /Users/serghei/Code/MyApp/node_modules/enhanced-resolve/lib  /forEachBail.js:16:12

Maybe it's relevant, I have the following script for starting cypress: cypress open --component --browser chrome --config-file ./cypress/cypress.config.js

[floverdevel]

I had the same problem with Cypress 10.10.0
I updated to 12.7.0 and the problem is gone for me, thank you very much, good job :)

[marktnoonan]

Ugh @scebotari66 I see, you get double cypress in /Users/serghei/Code/MyApp/cypress/cypress/support/component-index.html

I feel like we have enough to open a new issue around correctly getting the path to component-index.html when using a custom config file. Which is something we should be able to test for and fix pretty quickly.

If you switch down to v12.6.0 does this problem go away?

[scebotari66]

@marktnoonan, with v12.6.0 I get the same error as above when removing indexHtmlFile config. But it does not seem to crash when I am updating a spec file.