Allow to uninclude features

[nicojs]

Is your feature request related to a problem? Please describe.
Let's say you have this cucumber.js config:

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

And you now want to focus 1 feature in a feature file:

$ npx cucumber-js my-features/math.feature:7

In addition to the scenario on line 7 in math.feature, all other feature files will be executed. I've located the code that is responsible here:

cucumber-js/src/cli/configuration_builder.ts

Lines 125 to 141 in 4ef9710

	const expandedPaths = await bluebird.map(
	unexpandedPaths,
	async (unexpandedPath) => {
	const matches = await promisify(glob)(unexpandedPath, {
	absolute: true,
	cwd: this.cwd,
	})
	const expanded = await bluebird.map(matches, async (match) => {
	if (path.extname(match) === '') {
	return await promisify(glob)(`${match}/**/*${defaultExtension}`)
	}
	return [match]
	})
	return _.flatten(expanded)
	}
	)
	return _.flatten(expandedPaths).map((x) => path.normalize(x))

Describe the solution you'd like
I would personally think that command line positional arguments should not be merged together with the profile positional arguments, instead it should override them. Note: I do think properties should still be merged, just not positional arguments.

Describe alternatives you've considered
A way to "uninclude" files would be a valid alternative:

$ npx cucumber-js !**/*.feature my-feature/math.feature:7

Additional context
I've run into this while developing the cucumber plugin for StrykerJS. We want to be able to focus tests, regardless of positional arguments in the profile.

We can also think of another solution when defining the programmable API

[aurelien-reeves]

That makes sense to me

What do you think @cucumber/cucumber-js?

Another possibility could be also to have a --no-profile option to avoid loading any profile, including the default one.

[nicojs]

Thanks @aurelien-reeves .

A --no-profile would be useful as well for other use cases, but I also want to support profiles. For example:

module.exports = {
  default: '--require-module tsnode/register --require my-features/**/*.ts my-features/*.feature'
}

In this case I still want the options, just not the positional arguments 🤷‍♂️

[davidjgoss]

Thanks for raising @nicojs.

I'd be supportive of changing the logic with the paths so they are considered together and negation is supported. Basically what globby does. I don't think this is a breaking change for any use case I can think of, but at any rate we're doing a major release soon. @charlierudolph WDYT?

Good point about the API as well, I'll follow up on that issue.

[charlierudolph]

Hmm, I'm uncertain about if profile positional arguments should be added to or overridden by cli positional arguments. Maybe could have a flag --default-features <paths> which is the features used only if no positional arguments are passed. That would support the override case and allow us to keep the same positional arguments we have now.

If we want to support a method of excluding feature, I think that should also be done via a flag as I would want it to apply to all feature paths passed in and that makes more sense to me as a flag than a positional argument

[davidjgoss]

@nicojs I'm thinking you could address this use case with the new API, something like:

import {loadConfiguration, runCucumber} from '@cucumber/cucumber/api'

async function targetedRun(scenarioPath) {
  const {runConfiguration} = await loadConfiguration()
  const modifiedConfiguration = {
    ...runConfiguration,
    sources: {
      ..runConfiguration.sources,
      paths: [scenarioPath]
    }
  }
  return await runCucumber(modifiedConfiguration)
}

WDYT?

[davidjgoss]

Closing this now as it's been quiet, and I think (per above) the requirement can be solved using the new API.

[nicojs]

Yeah, I'm using the new API since Stryker V6.1 and it works great!