diff --git a/.markdownlint.yml b/.markdownlint.yml index a8478b2ae94..084bb03701e 100644 --- a/.markdownlint.yml +++ b/.markdownlint.yml @@ -7,7 +7,6 @@ MD004: # Unordered list style MD007: # Unordered list indentation indent: 4 MD013: false # Line length -MD014: false # Dollar signs used before commands without showing output MD019: false # Multiple spaces after hash on atx style header MD021: false # Multiple spaces inside hashes on closed atx style header MD024: false # Multiple headers with the same content diff --git a/README.md b/README.md index 86fabcf375e..63bff9ae824 100644 --- a/README.md +++ b/README.md @@ -48,19 +48,19 @@ Prerequisites: [Node.js](https://nodejs.org/) (`^12.22.0`, `^14.17.0`, or `>=16. You can install ESLint using npm: ```sh -$ npm install eslint --save-dev +npm install eslint --save-dev ``` You should then set up a configuration file: ```sh -$ npm init @eslint/config +npm init @eslint/config ``` After that, you can run ESLint on any file or directory like this: ```sh -$ ./node_modules/.bin/eslint yourfile.js +./node_modules/.bin/eslint yourfile.js ``` ## Configuration diff --git a/docs/developer-guide/contributing/pull-requests.md b/docs/developer-guide/contributing/pull-requests.md index f1d62e1e922..e67f2966985 100644 --- a/docs/developer-guide/contributing/pull-requests.md +++ b/docs/developer-guide/contributing/pull-requests.md @@ -31,7 +31,7 @@ Details about each step are found below. The first step to sending a pull request is to create a new branch in your ESLint fork. Give the branch a descriptive name that describes what it is you're fixing, such as: ```shell -$ git checkout -b issue1234 +git checkout -b issue1234 ``` You should do all of your development for the issue in this branch. @@ -43,8 +43,8 @@ You should do all of your development for the issue in this branch. Make the changes to the code and tests, following the [code conventions](../code-conventions.md) as you go. Once you have finished, commit the changes to your branch: ```shell -$ git add -A -$ git commit +git add -A +git commit ``` All ESLint projects follow [Conventional Commits](https://www.conventionalcommits.org/) for our commit messages. Here's an example commit message: @@ -150,13 +150,13 @@ Once your pull request is sent, it's time for the team to review it. As such, pl If your commit message is in the incorrect format, you'll be asked to update it. You can do so via: ```shell -$ git commit --amend +git commit --amend ``` This will open up your editor so you can make changes. After that, you'll need to do a forced push to your branch: ```shell -$ git push origin issue1234 -f +git push origin issue1234 -f ``` ### Updating the Code @@ -164,9 +164,9 @@ $ git push origin issue1234 -f If we ask you to make code changes, there's no need to close the pull request and create a new one. Just go back to the branch on your fork and make your changes. Then, when you're ready, you can add your changes into the branch: ```shell -$ git add -A -$ git commit -$ git push origin issue1234 +git add -A +git commit +git push origin issue1234 ``` When updating the code, it's usually better to add additional commits to your branch rather than amending the original commit, because reviewers can easily tell which changes were made in response to a particular review. When we merge pull requests, we will squash all the commits from your branch into a single commit on the `main` branch. @@ -178,12 +178,12 @@ The commit messages in subsequent commits do not need to be in any specific form If your code is out-of-date, we might ask you to rebase. That means we want you to apply your changes on top of the latest upstream code. Make sure you have set up a [development environment](../development-environment.md) and then you can rebase using these commands: ```shell -$ git fetch upstream -$ git rebase upstream/main +git fetch upstream +git rebase upstream/main ``` You might find that there are merge conflicts when you attempt to rebase. Please [resolve the conflicts](https://help.github.com/articles/resolving-merge-conflicts-after-a-git-rebase/) and then do a forced push to your branch: ```shell -$ git push origin issue1234 -f +git push origin issue1234 -f ``` diff --git a/docs/developer-guide/development-environment.md b/docs/developer-guide/development-environment.md index 5be51bd2c6e..f61c3eb6d2d 100644 --- a/docs/developer-guide/development-environment.md +++ b/docs/developer-guide/development-environment.md @@ -15,8 +15,8 @@ Go to and click the "Fork" button. Follow the Once you've cloned the repository, run `npm install` to get all the necessary dependencies: ```shell -$ cd eslint -$ npm install +cd eslint +npm install ``` You must be connected to the Internet for this step to work. You'll see a lot of utilities being downloaded. diff --git a/docs/user-guide/getting-started.md b/docs/user-guide/getting-started.md index eb0f34d6579..ef80229766c 100644 --- a/docs/user-guide/getting-started.md +++ b/docs/user-guide/getting-started.md @@ -23,11 +23,11 @@ yarn add eslint --dev You should then set up a configuration file, and the easiest way to do that is: ```shell -$ npm init @eslint/config +npm init @eslint/config # or -$ yarn create @eslint/config +yarn create @eslint/config ``` **Note:** `npm init @eslint/config` assumes you have a `package.json` file already. If you don't, make sure to run `npm init` or `yarn init` beforehand. @@ -35,11 +35,11 @@ $ yarn create @eslint/config After that, you can run ESLint on any file or directory like this: ```shell -$ npx eslint yourfile.js +npx eslint yourfile.js # or -$ yarn run eslint yourfile.js +yarn run eslint yourfile.js ``` It is also possible to install ESLint globally rather than locally (using `npm install eslint --global`). However, this is not recommended, and any plugins or shareable configs that you use must be installed locally in either case. diff --git a/docs/user-guide/migrating-from-jscs.md b/docs/user-guide/migrating-from-jscs.md index 7c79486e5c0..66e4fe7a206 100644 --- a/docs/user-guide/migrating-from-jscs.md +++ b/docs/user-guide/migrating-from-jscs.md @@ -16,7 +16,7 @@ Before beginning the process of migrating to ESLint, it's helpful to understand To install Polyjuice: ```shell -$ npm install -g polyjuice +npm install -g polyjuice ``` Polyjuice works with JSON configuration files, so if you're using a JavaScript or YAML JSCS configuration file, you should first convert it into a JSON configuration file. @@ -24,7 +24,7 @@ Polyjuice works with JSON configuration files, so if you're using a JavaScript o To convert your configuration file, pass in the location of your `.jscs.json` file using the `--jscs` flag: ```shell -$ polyjuice --jscs .jscsrc.json > .eslintrc.json +polyjuice --jscs .jscsrc.json > .eslintrc.json ``` This creates a `.eslintrc.json` with the equivalent rules from `.jscsrc.json`. @@ -32,7 +32,7 @@ This creates a `.eslintrc.json` with the equivalent rules from `.jscsrc.json`. If you have multiple `.jscsrc.json` files, you can pass them all and Polyjuice will combine them into one `.eslintrc.json` file: ```shell -$ polyjuice --jscs .jscsrc.json ./foo/.jscsrc.json > .eslintrc.json +polyjuice --jscs .jscsrc.json ./foo/.jscsrc.json > .eslintrc.json ``` **Note:** Polyjuice does a good job of creating a reasonable ESLint configuration from your JSCS configuration, but it may not be 100%. You may still see different warnings than you saw with JSCS, and so you may need to further modify your configuration after using Polyjuice. This is especially true if you're using inline comments to enable/disable certain rules in JSCS (you'll need to manually convert those to use ESLint-style comments instead, see "Disabling Rules Inline" later in this page). @@ -42,7 +42,7 @@ $ polyjuice --jscs .jscsrc.json ./foo/.jscsrc.json > .eslintrc.json If you don't want to convert your JSCS configuration directly into an ESLint configuration, then you can use ESLint's built-in wizard to get you started. Just run: ```shell -$ npm init @eslint/config +npm init @eslint/config ``` You'll be guided through a series of questions that will help you setup a basic configuration file to get you started. @@ -75,7 +75,7 @@ As an example, suppose that you are using the `airbnb` preset, so your `.jscsrc` In order to get the same functionality in ESLint, you would first need to install the `eslint-config-airbnb` shareable config package: ```shell -$ npm install eslint-config-airbnb-base --save-dev +npm install eslint-config-airbnb-base --save-dev ``` And then you would modify your configuration file like this: @@ -111,13 +111,13 @@ Both JSCS and ESLint have command line arguments corresponding to many of their JSCS uses the `--fix` option to apply automatic fixes to code: ```shell -$ jscs --fix file.js +jscs --fix file.js ``` ESLint has the same option: ```shell -$ eslint --fix file.js +eslint --fix file.js ``` ### `--auto-configure` @@ -125,13 +125,13 @@ $ eslint --fix file.js The JSCS `--auto-configure` option created a configuration based on what it found in a given file: ```shell -$ jscs --auto-configure file.js +jscs --auto-configure file.js ``` In ESLint, there's a similar option when you use `--init`. Just select "Inspect your JavaScript file(s)": ```shell -$ eslint --init +eslint --init ? How would you like to configure ESLint? (Use arrow keys) > Answer questions about your style Use a popular style guide @@ -143,15 +143,15 @@ $ eslint --init JSCS allows you to specify a configuration file to use on the command line using either `--config` or `-c`, such as: ```shell -$ jscs --config myconfig.json file.js -$ jscs -c myconfig.json file.js +jscs --config myconfig.json file.js +jscs -c myconfig.json file.js ``` Both flags are also supported by ESLint: ```shell -$ eslint --config myconfig.json file.js -$ eslint -c myconfig.json file.js +eslint --config myconfig.json file.js +eslint -c myconfig.json file.js ``` ## Piping Code Into ESLint @@ -159,11 +159,11 @@ $ eslint -c myconfig.json file.js In JSCS, you can pipe code in like this: ```shell -$ cat file.js | jscs +cat file.js | jscs ``` In ESLint, you can also pipe in code, but you need to use the `--stdin` flag: ```shell -$ cat file.js | eslint --stdin +cat file.js | eslint --stdin ``` diff --git a/docs/user-guide/migrating-to-5.0.0.md b/docs/user-guide/migrating-to-5.0.0.md index 372963163cd..01bd1e2a644 100644 --- a/docs/user-guide/migrating-to-5.0.0.md +++ b/docs/user-guide/migrating-to-5.0.0.md @@ -100,7 +100,7 @@ For compatibility, ESLint v5 will treat `ecmaFeatures: { experimentalObjectRestS Previous versions of ESLint silently ignored any nonexistent files and globs provided on the command line: ```bash -$ eslint nonexistent-file.js 'nonexistent-folder/**/*.js' # exits without any errors in ESLint v4 +eslint nonexistent-file.js 'nonexistent-folder/**/*.js' # exits without any errors in ESLint v4 ``` Many users found this behavior confusing, because if they made a typo in a filename, ESLint would appear to lint that file successfully while actually not linting anything.