update profile configuration file

[charlierudolph]

Current cucumber.js file

var common = [
  '--compiler js:babel-register',
  '--format progress',
  '--format rerun:@rerun.txt',
  '--format usage:usage.txt'
].join(' ')

module.exports = {
  'default': common,
  'node-4': common + ' --tags "not @node-6"',
};

Suggested update new cucumber.yml file (using references)

_common: &COMMON
  compiler: js:babel-register
  format:
    - progress
    - rerun:@rerun.txt
    - usage:usage.txt

default:
  <<: *COMMON

node-4:
  <<: *COMMON
  tags: not @node-6

@jbpros thoughts? We originally went with .js in order to avoid the clash with ruby's cucumber.yml but I don't see think thats as an issue. Aside from this project when I first joined, I've never seen a project that used both cucumber-ruby and cucumber-js. Nor can I think of a valid reason to do so.

@mattwynne you as well as you may be able to get rid of the erb support.

Mainly would like to allow users to not have put actual CLI options in here. The options mirror the long form of the CLI options but without the need of actually specifying them with all the --. Implementation wise you can still convert these to cli options pretty easily (on the javascript side the there is a javascript library for doing that: dargs.

[charlierudolph]

@jbpros @mattwynne bump

[mattwynne]

Hi @charlierudolph sorry I missed this the first time for some reason.

What I would truly ❤️ would be a one-size-fits all declarative .cucumber file (in whatever format, I don't mind) that's extensible enough to work with different cucumbers but uniform enough that it could be read by a tool. So YAML (or TOML, or JSON) would be a step in the right direction.

[charlierudolph]

Should nest the profile info under a profile key to make it more extensible as we can add in other things such as formatter-aliases in order to specify customer formatters with a nice name

[stevenmhunt]

@mattwynne @charlierudolph I started creating set of add-ons for Cucumber.js called cucumber-extra and one of the tools generates the ./cucumber.js using a yaml file. It would be awesome to have support for this built-in to Cucumber.js itself, but at least it's possible to get this experience now through an existing package.

[aslakhellesoy]

Let's pick this up again. See #1711 (comment) for some recent details. I'd love to have a JavaScript implementation of config for this! (@cucumber/config lib)

[davidjgoss]

@aslakhellesoy sounds good, I'll try and do this in conjunction with #1711.

I think it would make sense to keep this new thing separate from the existing cucumber.js file which would then become deprecated. It'd be good to move away from default as a key on module.exports - it's thrown up some issues when trying to switch to loading with await import() in #1649 (I'm now descoping the config file from that change).

On the naming of the files, what do we think about the unix-esque convention used by mocha, eslint etc:

.cucumberrc.json
.cucumberrc.yml
.cucumberrc.js

[davidjgoss]

Looking at this now as part of #1711, one thing I'd like to review about how config works today with the CLI and Profiles is the additive nature of it.

In other words, if you have a config file like:

// cucumber.js
module.exports = {
  default: 'my/features/dir/*.feature'
}

And then run:

$ npx cucumber-js my/features/dir/specific-thing.feature

It will concatenate the arguments rather than override. In this specific case, it's a problem because it stops you from narrowing the sources. With other things like formats, it's sometimes a strength - your default config can define a bunch of formatters, but you can specify others as needed via the CLI and/or other profiles. You can also invoke multiple profiles, and it all kind of gets layered on.

Some things we could do:

• Keep it this way
• Make it so that anything passed to the CLI will override the file-based config - this is more consistent with how config works in other things e.g. Jest, ESLint - and config from multiple profiles would still be combined to give the composability.