'ENOENT: no such file or directory, stat' when running .feature files for a specific branch or change

[skapegoat]

Current behavior

Whenever me or my co-worker modify something at our release branch, something very odd occurs: we start getting the "ENOENT: no such file or directory, stat" error.

Trying to give a better example:

• They merged a new branch on release with a new .feature file
• I update the release on my computer after they did so
• I couldn't run this new .feature file, but could run any other .feature files I already had

By looking at the error message, it looks like cypress is not taking the right path when searching for the .feature files

Error: ENOENT: no such file or directory, stat '/home/myUser/.config/Cypress/cy/production/projects/test-auto-hf8d5df2269211bd1439f0f01fa123456/bundles/cypress/e2e/frontend/foldercategory/folder_two/my_running_test.feature'

Desired behavior

Cypress would follow the specPattern and run the .feature tests as it does for my other .feature files

the specPattern of my cypress.config

'cypress/e2e/frontend/foldercategory/folderone/my_ok_running_test.feature'

Test code to reproduce

I don't know if there's any test code that can reproduce this error since it doesn't look like a code problem itself, but here is how my cypress.config.js is configured right now:

const { defineConfig } = require('cypress')
const allureWriter = require('@shelex/cypress-allure-plugin/writer')
const createBundler = require('@bahmutov/cypress-esbuild-preprocessor')
const preprocessor = require('@badeball/cypress-cucumber-preprocessor')
const createEsbuildPlugin = require('@badeball/cypress-cucumber-preprocessor/esbuild')

const configEnv = {
    aLotofEnvs: {
 configX: 'localhost'
    }
}

    e2e: {
       specPattern: ['**/*.feature', 'cypress/e2e/api/**/*.cy.js']
    }

Cypress Version

12.5.1

Node version

16.19.0

Operating System

Ubuntu 20.4

Debug Logs

No response

Other

I've found several topics with similar conditions, but no answer could help me. Tried following the clear cache steps on the documentation, updating libs and modifying the file itself, but nothing fixed the issue.

Also, I'm new to the area, so please forgive me if I didn't provide enough information, let me know what else I can provide to get any help on this.

[mike-plummer]

Hi @skapegoat , sorry to hear you're having trouble. Based on your description this is only happening for *.feature files which tells me there may be an issue with the @badeball/cypress-cucumber-preprocessor plugin. I see this issue has been previously reported there. I also notice you're using the @bahmutov/cypress-esbuild-preprocessor plugin which could also be introducing issues since that involves another bundler with independent caching - you may want to see if temporarily removing that plugin resolves your issue.

If you still aren't able to identify the issue and believe it's a bug in Cypress rather than an issue with one of your plugins we would need Debug Logs from a failing run and, ideally, a reproducible example to help us troubleshoot.

[mistic100]

@skapegoat I had the same error after updating all my dependencies. Turns out in my case it was a compilation error (bad import) of the feature support file (my_running_test.ts for example, next to my_running_test.feature) BUT the error was not visible anywhere.

I was able to see the esbuild error in cypress console only after downgrading both @bahmutov/cypress-esbuild-preprocessor (2.1) and @badeball/cypress-cucumber-preprocessor (14.0), and by transitivity, esbuild (0.14).

I don't know who is responsible of this bad error handling.

Hope it helps you.

[mike-plummer]

Unfortunately we have to close this issue due to inactivity. Please comment if there is new information to provide concerning the original issue and we can reopen.

[skapegoat]

Hello guys! First, thanks for all the answers! I'm sorry for answering only after the closing of the topic, but I just find out a way to solve my problem yesterday.

In my case, it was a problem with the folder structure on my project.
.
└── cypress/
├── e2e/
│ └── backend_folder/
│ └── backend_login_folder/
│ ├── backend_login.cy.js
│ └── backend_dont_login.cy.js
├── frontend_folder/
│ └── frontend_login_folder/
│ ├── frontend_login.feature
│ ├── frontend_dont_login.feature
│ └── | frontend_OTHER_TEST_folder/
│ └── | MY_OTHER_TEST.feature
└── support_folder/
├── backend_support_folder/
│ └── backend_support.js
└── frontend_definitions_folder/
├── frontend_objects_folder/
│ ├── frontend_login_objects.js
│ └── | frontend_OTHER_TEST_objects_folder/
│ └── | frontend_OTHER_TEST_objects.js
└── frontend_steps_folder/
├── frontend_login_steps.js
└── | frontend_OTHER_TEST_steps_folder/
└── | frontend_OTHER_TEST_steps.js

please see the structure better here

You can see that my OTHER_TEST had an extra folder on it's path regarding the objects and steps file, right? For internal reasons, we tried to add a new folder so the OTHER_TEST was aside from my login tests.

The problem me and my team discovered was that cucumber was having a hard time reading that extra folder and ended up not being able to find the definitions folder at all.

If I had a cache at the cypress folder for running the tests BEFORE the "OTHER_TEST" folders was created, then it would run all the tests without a problem.

If I delete the cache at the cypress folder and then try to run the tests AFTER the "OTHER_TEST" folders was created, then it would crash with the ENOENT error.

The solution was to just erase that extra path so it would turnout something like this:

    └── frontend_definitions_folder/
        ├── frontend_objects_folder/
        │   ├── frontend_login_objects.js
        │   ├── frontend_OTHER_TEST_objects.js
        └── frontend_steps_folder/
            ├── frontend_login_steps.js
            ├── frontend_OTHER_TEST_steps.js

[mike-plummer]

Thanks for circling back with the solution @skapegoat, glad you got it working!

[MRozycka]

@skapegoat I had the same error after updating all my dependencies. Turns out in my case it was a compilation error (bad import) of the feature support file (my_running_test.ts for example, next to my_running_test.feature) BUT the error was not visible anywhere.

I was able to see the esbuild error in cypress console only after downgrading both @bahmutov/cypress-esbuild-preprocessor (2.1) and @badeball/cypress-cucumber-preprocessor (14.0), and by transitivity, esbuild (0.14).

I don't know who is responsible of this bad error handling.

Hope it helps you.

@mistic100 It did help! This was the issue here in my case (a compilation error (bad import)). Thank you!!

[plumpNation]

I wanted to leave a note here because I also ran into this problem whilst using the cucumber preprocessing.

I couldn't understand why my feature file was not updating, even when I deleted all the tests in it, all the scenarios were still running in Cypress.

I believe this is because the previous bundle created by the preprocessor was being rerun each time the watch mechanism was triggered by the feature file save.

I deleted the bundled files in order to try to force a rebuild, but then I ended up getting the error reported in this issue. The feature files were never rebuilt.

Unfortunately for me, I had missed that there were errors in my cypress support and command files. This prevented the compilation/bundling of the updated test files, but did not stop the previously bundled test files from running. It could have easily been solved by simply running a linter.

So check your own code for errors that will stop it building correctly. An easy way to do this is to run the cypress run command instead of the cypress open. You should see errors in the terminal.

[PradeepSV006]

Hello guys! First, thanks for all the answers! I'm sorry for answering only after the closing of the topic, but I just find out a way to solve my problem yesterday.

In my case, it was a problem with the folder structure on my project. . └── cypress/ ├── e2e/ │ └── backend_folder/ │ └── backend_login_folder/ │ ├── backend_login.cy.js │ └── backend_dont_login.cy.js ├── frontend_folder/ │ └── frontend_login_folder/ │ ├── frontend_login.feature │ ├── frontend_dont_login.feature │ └── | frontend_OTHER_TEST_folder/ │ └── | MY_OTHER_TEST.feature └── support_folder/ ├── backend_support_folder/ │ └── backend_support.js └── frontend_definitions_folder/ ├── frontend_objects_folder/ │ ├── frontend_login_objects.js │ └── | frontend_OTHER_TEST_objects_folder/ │ └── | frontend_OTHER_TEST_objects.js └── frontend_steps_folder/ ├── frontend_login_steps.js └── | frontend_OTHER_TEST_steps_folder/ └── | frontend_OTHER_TEST_steps.js

please see the structure better here

You can see that my OTHER_TEST had an extra folder on it's path regarding the objects and steps file, right? For internal reasons, we tried to add a new folder so the OTHER_TEST was aside from my login tests.

The problem me and my team discovered was that cucumber was having a hard time reading that extra folder and ended up not being able to find the definitions folder at all.

If I had a cache at the cypress folder for running the tests BEFORE the "OTHER_TEST" folders was created, then it would run all the tests without a problem.

If I delete the cache at the cypress folder and then try to run the tests AFTER the "OTHER_TEST" folders was created, then it would crash with the ENOENT error.

The solution was to just erase that extra path so it would turnout something like this:

    └── frontend_definitions_folder/
        ├── frontend_objects_folder/
        │   ├── frontend_login_objects.js
        │   ├── frontend_OTHER_TEST_objects.js
        └── frontend_steps_folder/
            ├── frontend_login_steps.js
            ├── frontend_OTHER_TEST_steps.js

Great that is worked for you. I my case, I have all my tests.cy.ts files in the same folder. Some of them ran successfully, for the remaining I faced the same issue 'ENOENT: no such file or directory, stat'.

[cscsaba242]

I have to delete the branch and checkout again to fix this kind of error, hope it helps.

[mysticdevx]

Hi, This is already closed, but I want to note that this is still a valid issue, and almost impossible to create a repo for reproduction. (I have tried, but so far no success).
Environment:
Cypress: v13.3.1
Node: v18.17.1
Mac M1, OS 14.0
esbuild: v0.19.4
cucumber preprocessor: v18.0.6 (here)
esbuild-preprocessor: v.2.2.0 (here)

*It happens only in interactive (cypress open) mode; the cypress run command works fine. Even though I deleted all the previously compiled and cached folders under .../Cypress/cy/production/projects/.. I didn't get any error/warning log in run mode.

I have reinstalled all dependencies, cleared Cypress cache, checked for any wrong imports etc., with no success.

After reading all of the comments above and here - thanks guys, for all the inputs-, my temporary solution is:
I had the watchForFileChanges cypress configuration set to false for not restarting tests after each file change. Setting this to true (or basically removing it) has temporarily improved the situation. Now, at first, the error is still seen, but immediately Cypress refreshes, finds the file and runs the test. once the file is saved under the .../Cypress/cy/production/projects/.. location, then all runs as expected. (I am posting this here as a workaround and also may give you a hint about the reason behind the issue.)

I hope there will be a permanent solution to this issue.
Thanks

[GiftedMediaBJ]

Though closed this post comes first in google when you search for "cypress 'ENOENT: no such file or directory, stat'"
I found I had the same issue on my macbook. And I could not find anything that was causing this issue.

The only thing I knew was that before it worked and now it didn't. And before I had cypress version 12, and now it was 13.

I was about to clean install mac os on my macbook when I found this .pnp.cjs file and this .pnp.loader.mjs file.
Looking into the first file I saw 'cypress' in the file and so I renamed the file and tried running the tests again and then they worked.

Seems like a previous install of cypress added these .pnp files and was now blocking my tests.
So if you have this problem please check your home dir and see if you have these hidden .pnp files.

[mysticdevx]

Though closed this post comes first in google when you search for "cypress 'ENOENT: no such file or directory, stat'" I found I had the same issue on my macbook. And I could not find anything that was causing this issue.

The only thing I knew was that before it worked and now it didn't. And before I had cypress version 12, and now it was 13.

I was about to clean install mac os on my macbook when I found this .pnp.cjs file and this .pnp.loader.mjs file. Looking into the first file I saw 'cypress' in the file and so I renamed the file and tried running the tests again and then they worked.

Seems like a previous install of cypress added these .pnp files and was now blocking my tests. So if you have this problem please check your home dir and see if you have these hidden .pnp files.

Hi @GiftedMediaBJ
Could u also please share where did u find those files, and how did u rename? Thanks.

[GiftedMediaBJ]

Yes sure.
I found them in my homedir (/Users/giftedmedia/) using the terminal.
simply by doing ls -a
There i saw the .pnp files.

I renamed them by typing
mv .pnp.cjs PNPCJSFILE

to bring them back you can do a
mc PNPCJSFILE .pnp.cjs

[AutomateItEasyWay]

Commenting on a closed issue hoping this would help someone.

I was running into this issue after integrating esbuild, I ran test using cypress run command and then executed cypress open. That made the issue go away!

[Guilhermme]

Hello, if anyone still has any problem regarding the error in this thread. The following guide below resolves the issue.

Installing Cypress and Cucumber with Page Object

[aldefouw]

Hello, if anyone still has any problem regarding the error in this thread. The following guide below resolves the issue.

Installing Cypress and Cucumber with Page Object

@Guilhermme - I agree that your solution listed resolves this issue.

However, I'd urge some caution. The solution also seems to be using deprecated code by using v4.3.1 of what was formerly https://github.com/TheBrainFamily/cypress-cucumber-preprocessor before the transfer of ownership to badeball.

The code used is 3 years old now: https://github.com/badeball/cypress-cucumber-preprocessor/commits/v4.3.1/

I think it would be better to use a non esBuild loader that isn't impacted by this issue than to use the deprecated version of the cypress-cucumber-preprocessor.

My solution was to do this:

    const bundler = createBundler({
        plugins: [createEsbuildPlugin(config)],
    })

    on('file:preprocessor', async (file) => {
        //Attempt to watch files locally if we're in `npx cypress open` mode
        file.shouldWatch = !config.isTextTerminal
        return await bundler(file)
    })

This code waits until the bundler returns what it needs ... not sure if it's the most efficient but it seems to work reliably in both the npx cypress run and npx cypress open context.

[nids2307]

Hello, if anyone still has any problem regarding the error in this thread. The following guide below resolves the issue.
Installing Cypress and Cucumber with Page Object

@Guilhermme - I agree that your solution listed resolves this issue.

However, I'd urge some caution. The solution also seems to be using deprecated code by using v4.3.1 of what was formerly https://github.com/TheBrainFamily/cypress-cucumber-preprocessor before the transfer of ownership to badeball.

The code used is 3 years old now: https://github.com/badeball/cypress-cucumber-preprocessor/commits/v4.3.1/

I think it would be better to use a non esBuild loader that isn't impacted by this issue than to use the deprecated version of the cypress-cucumber-preprocessor.

My solution was to do this:

    const bundler = createBundler({
        plugins: [createEsbuildPlugin(config)],
    })

    on('file:preprocessor', async (file) => {
        //Attempt to watch files locally if we're in `npx cypress open` mode
        file.shouldWatch = !config.isTextTerminal
        return await bundler(file)
    })

This code waits until the bundler returns what it needs ... not sure if it's the most efficient but it seems to work reliably in both the npx cypress run and npx cypress open context.

What version of the the esbuild processor and cucumber cypress processor being used here?