Update plugin to be compatible with Cypress 10

[admah]

Hello 👋 I'm writing on behalf of the Cypress DX team. We wanted to notify you that some changes may need to be made to this plugin to ensure that it works in Cypress 10.

For more information, here is our official plugin update guide.

--

Note from @badeball (12.06.22): v11.0.0-rc1 compatible with Cypress 10 is relased, ref. #722 (comment).

[badeball]

Hey @admah, thanks for the heads up!

[mike-mccormick]

@badeball I'm game for helping test the changes if you like :)

[matthew-dahm]

This looks painful. Glad I have not updated to cypress 10.0

[xyngfei]

@admah can I confirm the current v4.3.1 is not supported for cypress > v10?

[badeball]

@xyngfei, v4.3.1 is not the current version, ref. #689.

[xyngfei]

@badeball, any idea how to resolve this issue since I just want to add this library into dev dependencies?
If I want to use the latest cypress version for development purposes.

npm install @badeball/cypress-cucumber-preprocessor --save-dev

[badeball]

Version 10 just isn’t supported yet. No ETA.

[lmiller1990]

I can help with migrating the plugin to Cypress 10. The main challenge I see so far is that this plugin wants to write to cypress.json, which is now cypress.config.js, which is not as simple as require->modify->write like a JSON file.

We have code internally that does something like:

updateCypressConfigWithField('e2e', { foo: 'bar' })

Which would do

import { defineConfig } from 'cypress'

export default defineConfig({
  e2e: {
    foo: 'bar'
  }
})

Include parsing the module to an AST and handle all the edge cases, etc.

We can expose a nice API to update the cypress.config if it will help with migration. I will need more time to look at this code base to understand, maybe someone more familiar with it can help me know the main points where you need to interact with the Cypress API and we can work together - the majority (like 98%) of the public API and most of the private APIs are the same.

[badeball]

Hey, @lmiller1990, thanks for reaching out. I don't believe there's anything in the plugin that writes back to the config, but if it was, then such API as you describe would definitely be helpful.

The biggest challenge will be updating badeball/cypress-configuration, which is a complete re-implementation of Cypress' configuration resolvement. As explained in its readme, this powers some other tools, including this preprocessor.

Most helpful would be to expose an API for this and make cypress-configuration unnecessary.

[lmiller1990]

I just did a quick scan and saw this

cypress-cucumber-preprocessor/test/run-all-specs.ts

Line 35 in cb6f788

path.join(this.tmpDir, "cypress.json"),

but it looks like it's using a tmp dir, maybe it's not relevant after all to my initial thoughts.

Interesting, I had not seen https://github.com/badeball/cypress-configuration. I'm not super clear on why this is necessary - if you can tell me what you want exposed, we can work on a nice way to expose it. The config resolution is complicated (ugh, too complicated, lol) so it's definitely better if we provide something, rather than try to reverse engineer it.

[rburr0]

Hi gays, as usual, yesterday updated the cypress as usually do when working with the project and I didn't expect so many changes at the same time. All my stuff has been migrated and all the folder structure has been changed which have done a big impact on my environment.
As heard from you in this forum the cypress-cucumber-preprocessor plugging is not compatible with the latest cypress version yet. When are you planning to release a new one that is compatible with the latest version of cypress?

[lmiller1990]

Depends how much work it will be! I think someone from Cypress will have to collaborate with @badeball to get this rolling. @admah is probably the best one to help coordinate this.

[JayceeZ]

I have tried some experimentations inside the code base to see exactly what is needed and I gathered the following:

• The @badeball/cypress-configuration package contains code to resolve the test files path
• The code today is resolving using integrationFolder and testFiles configuration properties
• Cypress team has removed completely those properties in favor of e2e.specPattern

The code based itself on the fact that integrationFolder is an absolute path, but e2e.specPattern is, a the name suggest, a pattern.
Hence the resolver needs fundamental changes in the way it behave, which is with 100% certainty a lot of work.

I don't think Cypress team can help much, this is about rewriting completely the way .feature files paths are resolved.
If we want this to work with Cypress 10, someone needs to get his hands dirty on the subject.

On my side I don't have the necessary knowledge about file resolutions to do a good job, if someone with more expertise can try it would be better.

Please note that you can clone the two repositories and link them using npm link + enabling the file watch.

[lmiller1990]

The @badeball/cypress-configuration package contains code to resolve the test files path
The code today is resolving using integrationFolder and testFiles configuration properties
Cypress team has removed completely those properties in favor of e2e.specPattern

I think all three of these can be solved in one go - I wonder if we can expose something in Cypress that gives plugins like cucumber whatever it needs. It sounds like this plugin just needs a list of specs.

If this is written as a plugin, it should have access to config which has all the information required - I'll need to look more closely to see what the blocker is, but I think we have a decent enough public API to work with.

[far11ven]

I'm using Cypress v10.0.2 with cucumber preprocessor v4.x.x which works fine for me I just keep my stepdefinitions in "integration" folder and it doesn't matter where you keep your feature files if you use "specPattern" correctly

[danbord]

I'm using Cypress v10.0.2 with cucumber preprocessor v4.x.x which works fine for me I just keep my stepdefinitions in "integration" folder and it doesn't matter where you keep your feature files if you use "specPattern" correctly

I tried upgrading cypress to v10 with cucumber-preprocessor plugin (v10.0.2)

Leaving my feature files in /e2e/ folder and the steps within the /integration/

The features are detected by cypress but when running it I end up with a "TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received undefined"

[far11ven]

@danbord I'm using "cypress-cucumber-preprocessor": "^4.2.0"

Take a look here: https://github.com/far11ven/Cypress-TestFramework/tree/develop/v10

[ericcmmi]

I'm running 4.3.1 with Cypress 10 with everything in the e2e folder which seems to work fine as long as I add "stepDefinitions": "cypress/e2e" in package.json so I'll probably use the previous version of the preprocessor in this configuration until there's an update to this version so I can use it for component testing also. Commented here in case it would help anyone and to follow this issue.

[Bertg]

The fix @ericcmmi suggested is working great for me!

[mathpunk]

I can't get @ericcmmi's solution working. When running a feature I get

The error was:

Error: Webpack Compilation Error
Module build failed (from ./node_modules/cypress-cucumber-preprocessor/loader.js):
Error: We've tried to resolve your step definitions at cypress/integration, but that doesn't seem to exist. As of version 2.0.0 it's required to set step_definitions in your cypress-cucumber-preprocessor configuration. Look for nonGlobalStepDefinitions and add stepDefinitions right next to it. It should match your cypress configuration has set for integrationFolder. We no longer rely on getting information from that file as it was unreliable and problematic across Linux/MacOS/Windows especially since the config file could have been passed as an argument to cypress.
    at handle (/Users/tomhenderson/lg/logicgate/platform/cypress/src/cypress/node_modules/@cypress/webpack-preprocessor/dist/index.js:180:23)...

which is surprising because I have no instance of the word 'integration' anywhere in my project. I'll follow along in case my situation is useful in diagnosis. I set stepDefinitions in package.json to "cypress/e2e".

[ericcmmi]

Here's my cypress-cucumber-preprocessor section. Adding that stepDefinitions line was the only change I made after going through all of the Cypress 10 recommended conversions.

"cypress-cucumber-preprocessor": { "nonGlobalStepDefinitions": true, "stepDefinitions": "cypress/e2e", "cucumberJson": { "generate": true, "outputFolder": "cypress/cucumber-json", "filePrefix": "", "fileSuffix": ".cucumber" } }

[mathpunk]

Oh silly, I put the stepDefinitions outside the cypress-cucumber-preprocessor section. That's got me in a working state, thanks!

[badeball]

Posting for reference, from badeball/cypress-configuration#2 (comment):

@lmiller1990 and @admah, is this something we can request that Cypress expose for us? Either a complete configuration resolvement or simply a method for resolving test files given [cwd, argv, env].

Bear in mind that this plugin powers https://github.com/badeball/cypress-parallel and an (hopefully) upcoming vscode extension for Cypress + Cucumber, both of which does not have the luxury of access to the config object as a regular Cypress plugin has.

@lmiller1990 and @admah, can either of you comment on this?

[admah]

@badeball my recommendation would be to file an issue in the core repo outlining the problem here. That way, more users can see it, and the core team can address it accordingly. I definitely understand the ask and the importance of the feature request, but neither me or @lmiller1990 can unilaterally say how/when something like this could get done.

[badeball]

In that case, can you perhaps open up cypress-io/cypress#9014 with a reference to my comment?

I’ll be frank too, with you and everyone else here. I don’t at all expect you to expose anything to benefit v10 compatibility and that the configuration module need to be continued. Furthermore, I am well aware of what needs to be done and fully prepared to do the remaining work after @Anthony-Champagne-Wiztivi has been so kind and to start, I just haven’t gotten around to it yet.

[lmiller1990]

I'm more interested in exposing an API, not just for this plugin specifically, but for generally making it easier to build Cypress plugins.

From what I'm seeing here, it's not too difficult to get this working with Cypress 10 as it stands - maybe we don't need to expose anything, after all. I'm guessing the reason the #9014 is a lot of work is less how much code we need to expose it, but more around the documentation/commitment to not breaking something that becomes part of the public API...

[badeball]

commitment to not breaking something that becomes part of the public API

FYI, for my part, you may very well consider it experimental and not subject to semver, as long as you also expose a version number enabling me to create conditions.

[badeball]

@lmiller1990, I realize now that the mentioned updateCypressConfigWithField(...) would be very useful to me. Are you able to expose this? (ping @admah)

Edit: Feel free to obscure the location of such member, as to make it apparent it not a member of the public API.

[lmiller1990]

@badeball not sure, but can look into it - with a bunch of things to fix around our latest release, I don't think it'll be something that happens in the next few weeks, since documented or not, we will need to consider the ramifications of exposing such an API.

What is the main use case here? What field(s) do you need to add/remove? Maybe there's a more lightweight and simple way to do it in user land.

[bjoshi-codal]

Here's my cypress-cucumber-preprocessor section. Adding that stepDefinitions line was the only change I made after going through all of the Cypress 10 recommended conversions.

"cypress-cucumber-preprocessor": { "nonGlobalStepDefinitions": true, "stepDefinitions": "cypress/e2e", "cucumberJson": { "generate": true, "outputFolder": "cypress/cucumber-json", "filePrefix": "", "fileSuffix": ".cucumber" } }

Is it working fine then ?

[badeball]

What is the main use case here? What field(s) do you need to add/remove? Maybe there's a more lightweight and simple way to do it in user land.

I have a function in my test called addOrUpdateConfiguration(), which facilitates tests that read

Given additional Cypress configuration
  """
  {
    "screenshotOnRunFailure": false,
    "retries": 1
  }
  """

.. but I can work around it.

[ericcmmi]

@bjoshi-codal it works for the e2e tests but not the component tests. I tried setting the stepDefinitions to cypress/component but it wouldn't run the tests in that configuration.

[KyleVassella]

I'm running 4.3.1 with Cypress 10 with everything in the e2e folder which seems to work fine as long as I add "stepDefinitions": "cypress/e2e" in package.json so I'll probably use the previous version of the preprocessor in this configuration until there's an update to this version so I can use it for component testing also. Commented here in case it would help anyone and to follow this issue.

@ericcmmi this got me closer, but I’m getting ‘step implementation missing’ error. My folder structure is:

Feature file: e2e/myFirstTest.feature
Step file: e2e/myFirstTest/myFirstTest.js

Can you share your file/folder structure within e2e, and the contents of your cypress.config.ts?

EDIT: nevermind, I got it. I was one word off on the feature wording vs the spec wording. My test appears to work properly now with Cypress 10 and cypress-cucumber-preprocessor - at least so far. Thanks @ericcmmi

[badeball]

I'm pleased to announce that I've published @badeball/[email protected], with great help from @Anthony-Champagne-Wiztivi who's done a lot of the legwork. It's source resides in 90b3a90, IE. it's not pushed to master yet and it's documentation is still to follow. I've published is primarily to gain some initial feedback and to see if there's something obvious I've missed.

There's no changes to configuration options, but if your configuration looked like this pre-10

{
  "stepDefinitions": [
    "cypress/integration/[filepath].{js,ts}",
    "cypress/support/step_definitions/**/*.{js,ts}"
  ]
}

.. then it should look like this post-10 (notice the removal of cypress/integration)

{
  "stepDefinitions": [
    "[filepath].{js,ts}",
    "cypress/support/step_definitions/**/*.{js,ts}"
  ]
}

If you need help getting 11.0.0-rc1 to work, then a RC is not for you and you should wait for the proper release. I don't want to clutter up the issue with nonsense now.

Please try it out and provide feedback here, both if it works and how it doesn't.

[alee13-chwy]

Cucumber has a built in cypress-tags however it hardcoded to cypress/integration if cypress.json does not exist. see line 33 in cypress-cucumber-preprocessor/cypress-tags.js

[badeball]

I said I don't want to clutter up the issue with nonsense, so the next person who comments on this issue about workarounds using the previous implementation / old versions is insta-banned from the issue tracker.

[manoj-mukherjee-maersk]

Feedback: After following #722 (comment)

• Update latest 11 version
• Update latest Cypress
  Everything working. Great work, Thank you @badeball

[manoj-mukherjee-maersk]

Is any change required to generate XRAY report with Cypress 10 and @badeball/[email protected]?

[danbord]

Got it to work too with rc1 and cypress 10.1. Thank you @badeball & @Anthony-Champagne-Wiztivi!

[badeball]

RC1 has been published as v11.0.0 and support for 10 officially (and finally) added, hence closing.

[far11ven]

@badeball the release notes says "Added support for Cypress v11" cypress v11 isn't out right now, is that right?

[lmiller1990]

I think it's "v11 of this plugin supports Cypress v10" 👍

[okabache]

If we decide to use Oldschool/Legacy Cucumber style, is it works too?

[badeball]

I doubt it, but why would you?

[okabache]

To reorganize the features in our own way and not necessarily put them in the E2E folder
Exemple :

  "cypress-cucumber-preprocessor": {
    "nonGlobalStepDefinitions": false,
    "stepDefinitions": "cypress/src/steps_definition",
    "commonPath": "cypress/src/definitions_etapes"
  },

[badeball]

On a completely general note I would say that you should never refrain from updating in order to achieve something and you certainly won’t get any support when doing so.