Cypress-cucumber-preprocessor: fileServerFolder option is being used incorrectly

[reaktivo]

First off, I would like to show my appreciation for this project, it's something that I've been looking for for a while now, and I'm glad you open sourced it!

The issue is that the fileServerFolder option is being used incorrectly to look for step definitions, when it actual use case is to allow cypress to start a local http static assets folder from this path.

I've created a PR here #17

[lgandecki]

Hmm... I asked the cypress guys about where would be a good place to put support files like this and the answer was "that's a good question" ;-).
Could you explain a bit more in what cases the use of fileServerFolder for step_definitions is causing issues?
Or are you just worried (probably correctly) that we are mixing responsibilities here?

[lgandecki]

Oh wait.. I think I get this ..

@dvelasquez @gpincheiraa I think @reaktivo is right, somehow I assumed that the fileServerFolder is the path to the support/ and you just changed the default there. But now I see that those are two completely separate paths. It was my mistake to merge it ( https://github.com/TheBrainFamily/cypress-cucumber-preprocessor/pull/5 ).
@reaktivo do you have an idea what would be a better way of using a custom folder here?

@dvelasquez @gpincheiraa could you explan why couldn't you keep your step_definitions files directly in the cypress/support ?

[reaktivo]

Ah! I now see you're referencing #5, might make sense to create a namespaced object in the same cypress.json config file which specifies cypress-cucumber-preprocessor options, like where step definitions should be found.

[lgandecki]

yeah, that could make sense... I wish we had some feedback from the cypress guys here..
@brian-mann @bahmutov what do you think of us (or other plugins) adding custom properties to the cypress.json ?

[dvelasquez]

@lgandecki sure, the default path of installation of cypress is in the root of the project, but for me, that default doesn't match my current scaffolding. This is directory structure:

/src <-- Source files (vuejs)
/tests <-- Test root folder
/tests/unit <-- units tests
/tests/e2e <-- Cypress content goes here

So, in my case, i don't want to keep a cypress folder polluting the root of the project.
But, this plugin has the directory /cypress/support/ hardcoded, so, what i try was just to make this module to be aware of the custom directory cypress folder.

But, if we can add to cypress.json a specific value to our step_definition folder, that should be great.

Another way is adding a custom config to the package.json file adding the route of our step definition files.

[brian-mann]

If you rename all of the cypress folders per configuration it should/will not create a cypress folder.

https://docs.cypress.io/guides/references/configuration.html#Folders-Files

[lgandecki]

@brian-mann yes it won't create cypress folder but then we still have to tell the cucumber-preprocessor where to look for step_definitions.
It would be great to have some kind of a "cypressRoot" configuration (that would point to cypress/ by default). I think @dvelasquez assumed that the fileServerFolder is that (and with the PR from him I assumed that's indeed the case).

I see two options here:
1) the "rootFolder" option
2) adding a custom property to the configuration, some options for that:

• cucumberPreprocessor object inside the configuration (and inside it we set stepDefinitionsFolder)
• directly putting cucumberPreprocessorStepDefinitionsFolder on the top level
• having sometihng like pluginsConfiguration: {}

[dvelasquez]

@lgandecki that was the case.

In this scenario, i'll vote for a package.json configuration, like the custom configurations for "jest" or "nightwatch".

{
  "cypress-cucumber-preprocessor": {
    "stepsFolder": "/tests/e2e/steps_definition",
    "scenarios":  "/tests/e2e/scenarios"
  }
}

[reaktivo]

@brian-mann is there a best practice for defining plugin configs? I would rather read the both the cypress config and it's plugins from the same file. And considering we have access to the parsed config at plugin loading time, we might as well pass that config:

// In cypress/plugins/index.js
const cucumber = require('cypress-cucumber-preprocessor').default
module.exports = (on, config) => {
  on('file:preprocessor', cucumber(config)) // Note that we're passing the config to the plugin here
}

in my cypress.json file:

{
  "viewportWidth": 1000,
  "viewportHeight": 660,
  "fileServerFolder": "build",
  "cypressCucumber": {
    "stepDefinitions": "tests/e2e/step_definitions"
  }
}

[lgandecki]

quick update - if the cypress guy don't reply by the middle of next week I will implement it in cypress.json with the syntax proposed by @reaktivo

[lgandecki]

@brian-mann @bahmutov guys? Any pointers from you? I feel like it should be up to you to establish patterns about plugins configuration. I'm implementing this tomorrow and will add a custom cypressCucumber object property to the cypress.json file if I don't hear back from you with different proposition. :)
Thanks!

[reaktivo]

Yesterday I played around with some different solutions

1. Adding a cypressCucumber key to cypress.json

I gave this idea a try and it kind of felt prone to error. Considering cypress config options may also be passed via env variables, cli --config flags, etc, having cypress-cucumber-preprocessor read the config json file directly without taking into account the previously mentioned sources of config feels like the wrong way to go.

1. Using the config that is passed to the plugin configuration function, like so:

const cucumber = require('cypress-cucumber-preprocessor').default
module.exports = (on, config) => {
  config.cypressCucumber = {};
  on('file:preprocessor', cucumber(config)) // notice config being passed here
}

I found out Cypress whitelists the properties that will be included in that config object, what I mean that adding a "something": "value" into your cypress.json won't include it in the config argument passed to the plugin configuration function. Also, some refactoring would need to happen so we append browserifyOptions instead of overwriting them.

1. Creating a new cypress-cucumber.json at project root level
   Although not ideal, it works in a predictable way and is guaranteed to be compatible with future cypress versions.

P.D As a temporary solution for those wanting to define fileServerFolder without your step definitions path incorrectly set, you can simply pass it as a cli option, and it will be ignored by the cypress-cucumber-preprocessor plugin.

cypress run --config fileServerFolder=build

[lgandecki]

Thank you so much for the research @reaktivo !
I'm still conflicted what to do about this. You are right.. That's why I was hoping to get some input from cypress guys, I asked about this basically the moment I created a plugin, and I also asked Brian about this in person recently...
This is, as far as I know, the only existing cypress plugin not made by the cypress guys, so it's hard to even get some patterns from someone else :)

cypress-cucumber.json is definitely not ideal, if we go that root I'd suggest a node module that reads the configuration from package.json OR custom .json file OR from process.env . I forgot the name of it.. something about a cosmos, I think :) I'm shooting to a meeting now but I will try to find it after

[lgandecki]

@reaktivo how would you feel about something like this - https://github.com/davidtheclark/cosmiconfig ?

[lgandecki]

This is fixed in 0.4.0 , please give it a try, and if still doesn't work as needed please create a new issue.
Thanks for all the discussion and ideas. Once you set
"cypress-cucumber-preprocessor": {
"step_definitions": "/"
}

in your package.json file it should ignore fileServerFolder.

Please let me know if it doesn't fix your problems.