Removed $ from README.md (#2372)

README.md

@@ -28,7 +28,7 @@ Looking to contribute? Read our [code of conduct](https://github.com/cucumber/.g
 Cucumber is [available on npm](https://www.npmjs.com/package/@cucumber/cucumber):
 
 ```shell
-$ npm install @cucumber/cucumber
+npm install @cucumber/cucumber
 ```
 
 ## Get Started
@@ -79,7 +79,7 @@ Then('I should have heard {string}', function (expectedResponse) {
 Finally, run Cucumber:
 
 ```shell
-$ npx cucumber-js
+npx cucumber-js
 ```
 
 And see the output:

docs/cli.md

@@ -3,7 +3,7 @@
 Cucumber includes an executable file to run your scenarios. After installing the `@cucumber/cucumber` package, you can run it directly:
 
 ``` shell
-$ ./node_modules/.bin/cucumber-js
+./node_modules/.bin/cucumber-js
 ```
 
 Or via a [`package.json` script](https://docs.npmjs.com/cli/v8/using-npm/scripts):
@@ -19,7 +19,7 @@ Or via a [`package.json` script](https://docs.npmjs.com/cli/v8/using-npm/scripts
 Or via [npx](https://docs.npmjs.com/cli/v8/commands/npx):
 
 ``` shell
-$ npx cucumber-js
+npx cucumber-js
 ```
 
 ## Options
@@ -39,15 +39,15 @@ Additionally, there are a few options that are specific to the CLI:
 To see the available options for your installed version, run:
 
 ```shell
-$ cucumber-js --help
+cucumber-js --help
 ```
 
 ## Exiting
 
 By default, cucumber exits when the event loop drains. Use the `forceExit` configuration option in order to force shutdown of the event loop when the test run has finished:
 
 - In a configuration file `{ forceExit: true }`
-- On the CLI `$ cucumber-js --force-exit`
+- On the CLI `cucumber-js --force-exit`
 
 This is discouraged, as fixing the issues that causes the hang is a better long term solution. Some potential resources for that are:
 * [Node.js guide to debugging](https://nodejs.org/en/docs/inspector/)

docs/configuration.md

@@ -18,7 +18,7 @@ You can keep your configuration in a file. Cucumber will look for one of these f
 You can also put your file somewhere else and tell Cucumber via the `--config` CLI option:
 
 ```shell
-$ cucumber-js --config config/cucumber.json
+cucumber-js --config config/cucumber.json
 ```
 
 Here's a concise example of a configuration file in JSON format:
@@ -112,7 +112,7 @@ features/**/*.{feature,feature.md}
 If your features are somewhere else, you can override this by proving your own [glob](https://github.com/isaacs/node-glob) or directory:
 
 - In a configuration file `{ paths: ['somewhere-else/**/*.feature'] }`
-- On the CLI `$ cucumber-js somewhere-else/**/*.feature`
+- On the CLI `cucumber-js somewhere-else/**/*.feature`
 
 This option is repeatable, so you can provide several values and they'll be combined.
 
@@ -130,7 +130,7 @@ By default, Cucumber finds support code files with this logic:
 If your files are somewhere else, you can override this by proving your own [glob](https://github.com/isaacs/node-glob), directory or file path to the `import` configuration option:
 
 - In a configuration file `{ import: ['somewhere-else/support/*.js'] }`
-- On the CLI `$ cucumber-js --import somewhere-else/support/*.js` 
+- On the CLI `cucumber-js --import somewhere-else/support/*.js` 
 
 Once you specify any `import` options, the defaults described above are no longer applied. The option is repeatable, so you can provide several values and they'll be combined, meaning you can load files from multiple locations.
 

docs/dry_run.md

@@ -3,7 +3,7 @@
 You can run cucumber-js in "Dry Run" mode:
 
 - In a configuration file `{ dryRun: true }`
-- On the CLI `$ cucumber-js --dry-run`
+- On the CLI `cucumber-js --dry-run`
 
 The effect is that Cucumber will still do all the aggregation work of looking at your feature files, loading your support code etc but without actually executing the tests. Specifically:
 

docs/esm.md

@@ -61,5 +61,5 @@ export const ci = {
 You can use [ESM loaders](https://nodejs.org/api/esm.html#loaders) to transpile your support code on the fly. The `requireModule` configuration option only works with CommonJS (i.e. `require` hooks) and is not applicable here. Cucumber doesn't have an equivalent option for ESM loaders because they currently can't be registered in-process, so you'll need to declare the loader externally, like this:
 
 ```shell
-$ NODE_OPTIONS="--loader <loader>" npx cucumber-js
+NODE_OPTIONS="--loader <loader>" npx cucumber-js
 ```

docs/fail_fast.md

@@ -1,7 +1,7 @@
 # Failing Fast
 
 - In a configuration file `{ failFast: true }`
-- On the CLI `$ cucumber-js --fail-fast`
+- On the CLI `cucumber-js --fail-fast`
 
 By default, Cucumber runs the entire suite and reports all the failures. `failFast` allows a developer workflow where you work on one failure at a time. Combining this feature with rerun files allows you to work through all failures in an efficient manner.
 

docs/filtering.md

@@ -7,12 +7,12 @@ You can use a few different configurations to have Cucumber filter which scenari
 You can specify an individual feature file to be run:
 
 - In a configuration file `{ paths: ['features/my_feature.feature'] }`
-- On the CLI `$ cucumber-js features/my_feature.feature`
+- On the CLI `cucumber-js features/my_feature.feature`
 
 You can also specify a line within a file to target an individual scenario:
 
 - In a configuration file `{ paths: ['features/my_feature.feature:3'] }`
-- On the CLI `$ cucumber-js features/my_feature.feature:3`
+- On the CLI `cucumber-js features/my_feature.feature:3`
 
 This option is repeatable, so you can provide several values and they'll be combined.
 
@@ -21,7 +21,7 @@ This option is repeatable, so you can provide several values and they'll be comb
 You can specify a regular expression against which scenario names are tested to filter which should run:
 
 - In a configuration file `{ name: ['^start.+end$'] }`
-- On the CLI `$ cucumber-js --name "^start.+end$"`
+- On the CLI `cucumber-js --name "^start.+end$"`
 
 To escape special regex characters in scenario name, use backslashes e.g., `\(Scenario Name\)`
 
@@ -32,7 +32,7 @@ This option is repeatable, so you can provide several expressions and they'll al
 You can specify a [Cucumber tag expression](https://docs.cucumber.io/cucumber/api/#tag-expressions) to only run scenarios that match it:
 
 - In a configuration file `{ tags: '@foo or @bar' }`
-- On the CLI `$ cucumber-js --tags "@foo or @bar"`
+- On the CLI `cucumber-js --tags "@foo or @bar"`
 
 This option is repeatable, so you can provide several expressions and they'll be combined with an `and` operator, meaning a scenario needs to match all of them.
 
@@ -41,7 +41,7 @@ This option is repeatable, so you can provide several expressions and they'll be
 You can specify the order that scenarios should run in:
 
 - In a configuration file `{ order: 'defined' }`
-- On the CLI `$ cucumber-js --order defined`
+- On the CLI `cucumber-js --order defined`
 
 The default is `defined` where scenarios are run in the order they are discovered in. This roughly means alphabetical order of file path followed by sequential order within each file, although if you pass multiple globs/paths to the `paths` option this order will be honoured.
 

docs/formatters.md

@@ -7,7 +7,7 @@ cucumber-js provides many built-in Formatters, plus building blocks with which y
 You can specify one or more formats via the `format` configuration option:
 
 - In a configuration file `{ format: ['progress-bar', ['html', 'cucumber-report.html']] }`
-- On the CLI `$ cucumber-js --format progress-bar --format "html":"cucumber-report.html"`
+- On the CLI `cucumber-js --format progress-bar --format "html":"cucumber-report.html"`
 
 For each format you specify, you have to provide one or two values. The first (required) is to identify the formatter. It can take a few forms:
 
@@ -30,7 +30,7 @@ Some notes on specifying Formatters:
 Many formatters, including the built-in ones, support some configuration via options. You can provide this data as an object literal via the `formatOptions` configuration option, like this:
 
 - In a configuration file `{ formatOptions: { someOption: true } }`
-- On the CLI `$ cucumber-js --format-options '{"someOption":true}'`
+- On the CLI `cucumber-js --format-options '{"someOption":true}'`
 
 This option is repeatable, so you can use it multiple times and the objects will be merged with the later ones taking precedence.
 

docs/installation.md

@@ -3,13 +3,13 @@
 With [npm](https://www.npmjs.com/):
 
 ```shell
-$ npm install @cucumber/cucumber
+npm install @cucumber/cucumber
 ```
 
 With [Yarn](https://yarnpkg.com/):
 
 ```shell
-$ yarn add @cucumber/cucumber
+yarn add @cucumber/cucumber
 ```
 
 ## Invalid installations

docs/parallel.md

@@ -3,7 +3,7 @@
 Cucumber supports running scenarios in parallel. The main process becomes a "coordinator" and spins up several separate Node.js processes to be the "workers". You can enable this with the `parallel` configuration option:
 
 - In a configuration file `{ parallel: 3 }`
-- On the CLI `$ cucumber-js --parallel 3`
+- On the CLI `cucumber-js --parallel 3`
 
 The number you provide is the number of workers that will run scenarios in parallel.
 

docs/profiles.md

@@ -5,13 +5,13 @@ If you have several permutations of running Cucumber with different options in y
 Profiles are invoked from the command line using the `--profile` CLI option.
 
 ```shell
-$ cucumber-js --profile my_profile
+cucumber-js --profile my_profile
 ```
 
 The short tag is `-p`
 
 ```shell
-$ cucumber-js -p my_profile
+cucumber-js -p my_profile
 ```
 
 ## Simple Example
@@ -64,15 +64,15 @@ module.exports = {
 Now, if we just run `cucumber-js` with no arguments, it will pick up our profiles and use the `default` one.  To run the CI profile we will use this command:
 
 ```shell
-$ cucumber-js -p ci
+cucumber-js -p ci
 ```
 
 ## Using Profiles for Arguments
 
 Cucumber doesn't allow custom command line arguments. For example:
 
 ```shell
-$ cucumber-js --myArgument
+cucumber-js --myArgument
 ```
 
 The above will result in `error: unknown option '--myArgument'`.
@@ -96,7 +96,7 @@ module.exports = {
 With it in place we can invoke a test of the iPhone with this command:
 
 ```shell
-$ cucumber-js -p webkit -p phone
+cucumber-js -p webkit -p phone
 ```
 
 The world parameter arguments from the two profile calls will be merged. If you pass profiles that try to set the same parameter, the last one passed in the chain will win out.

docs/rerun.md

@@ -14,7 +14,7 @@ Rerun makes this kind of workflow convenient, so you don't have to hand-craft co
 First, enable the `rerun` formatter every time you run cucumber-js:
 
 - In a configuration file `{ format: ['rerun:@rerun.txt'] }`
-- On the CLI `$ cucumber-js --format rerun:@rerun.txt`
+- On the CLI `cucumber-js --format rerun:@rerun.txt`
 
 You can do this via the CLI, or more likely via a [default profile](./profiles.md).
 
@@ -35,7 +35,7 @@ If this notation looks familiar, it's the same as for specifying scenarios by li
 So, let's say we've looked at the failure on `editing.feature` and fixed our code. Now let's run cucumber-js again, but pointing at the rerun file:
 
 ```shell
-$ cucumber-js @rerun.txt
+cucumber-js @rerun.txt
 ```
 
 cucumber-js will unpack this and just run those three failing scenarios accordingly. This time, it goes a bit better - our fix worked, and the rerun file now looks like this:
@@ -51,6 +51,6 @@ In other words, the one we fixed has passed and thus dropped off. We can repeat
 By default, entries in the rerun file are separated by newlines. This can be overwritten via a [format option](./formatters.md#options):
 
 - In a configuration file `{ formatOptions: { rerun: { separator: '<separator>' } } }`
-- On the CLI `$ cucumber-js --format-options '{"rerun": {"separator": "<separator>"}}'`
+- On the CLI `cucumber-js --format-options '{"rerun": {"separator": "<separator>"}}'`
 
 This is useful when one needs to rerun failed tests locally by copying a line from a CI log while using a space character as a separator. Note that the rerun file parser can only work with the default separator for now.

docs/retry.md

@@ -5,7 +5,7 @@
 If you have a flaky scenario (e.g. failing 10% of the time for some reason), you can use *Retry* to have Cucumber attempt it multiple times until either it passes or the maximum number of attempts is reached. You enable this via the `retry` configuration option, like this:
 
 - In a configuration file `{ retry: 1 }`
-- On the CLI `$ cucumber-js --retry 1`
+- On the CLI `cucumber-js --retry 1`
 
 The number you provide is the number of retries that will be allowed after an initial failure.
 
@@ -22,4 +22,4 @@ Some notes on how Retry works:
 Using the `retry` option alone would mean every scenario would be allowed multiple attempts - this almost certainly isn't what you want, assuming you have a small set of flaky scenarios. To target just the relevant scenarios, you can provide a [tag expression](https://cucumber.io/docs/cucumber/api/#tag-expressions) via the `retryTagFilter` configuration option, like this:
 
 - In a configuration file `{ retry: 1, retryTagFilter: '@flaky' }`
-- On the CLI `$ cucumber-js --retry 1 --retry-tag-filter @flaky`
+- On the CLI `cucumber-js --retry 1 --retry-tag-filter @flaky`

docs/transpiling.md

@@ -5,7 +5,7 @@ Step definitions and support files can be written in a syntax or language that c
 For example, you might want to use [Babel](https://babeljs.io/):
 
 - In a configuration file `{ requireModule: ['@babel/register'] }`
-- On the CLI `$ cucumber-js --require-module @babel/register`
+- On the CLI `cucumber-js --require-module @babel/register`
 
 This would mean any support code loaded with the `require` option would be transpiled first then loaded into Cucumber.
 
@@ -52,7 +52,7 @@ Note: One possible way to set an environment is to use the [cross-env](https://w
 If you are using babel with [@babel/preset-typescript](https://babeljs.io/docs/en/babel-preset-typescript):
 
 - In a configuration file `{ requireModule: ['@babel/register'], require: ['step-definitions/**/*.ts'] }`
-- On the CLI `$ cucumber-js --require-module @babel/register --require 'step-definitions/**/*.ts'`
+- On the CLI `cucumber-js --require-module @babel/register --require 'step-definitions/**/*.ts'`
 
 ### ESM