# prettier-eslint **Repository Path**: mirrors_addons/prettier-eslint ## Basic Information - **Project Name**: prettier-eslint - **Description**: Code :arrow_right: `prettier` :arrow_right: `eslint --fix` :arrow_right: Formatted Code :sparkles: - **Primary Language**: Unknown - **License**: MIT - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 0 - **Created**: 2020-05-03 - **Last Updated**: 2025-08-09 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README # prettier-eslint Formats your JavaScript using [`prettier`][prettier] followed by [`eslint --fix`][eslint] [![Build Status][build-badge]][build] [![Code Coverage][coverage-badge]][coverage] [![version][version-badge]][package] [![downloads][downloads-badge]][npm-stat] [![MIT License][license-badge]][license] [](https://opencollective.com/prettier-eslint) [](#contributors) [![PRs Welcome][prs-badge]][prs] [![Donate][donate-badge]][donate] [![Code of Conduct][coc-badge]][coc] [![Examples][examples-badge]][examples] [![Watch on GitHub][github-watch-badge]][github-watch] [![Star on GitHub][github-star-badge]][github-star] [![Tweet][twitter-badge]][twitter] ## The problem The [`fix`][fix] feature of [`eslint`][eslint] is pretty great and can auto-format/fix much of your code according to your ESLint config. [`prettier`][prettier] is a more powerful automatic formatter. One of the nice things about prettier is how opinionated it is. Unfortunately, it's not opinionated enough and/or some opinions differ from my own. So after prettier formats the code, I start getting linting errors. ## This solution This formats your code via `prettier`, and then passes the result of that to `eslint --fix`. This way you can get the benefits of `prettier`'s superior formatting capabilities, but also benefit from the configuration capabilities of `eslint`. > For files with an extension of `.css`, `.less`, `.scss`, or `.json` this only > runs `prettier` since `eslint` cannot process those. ## Installation This module is distributed via [npm][npm] which is bundled with [node][node] and should be installed as one of your project's `devDependencies`: ``` npm install --save-dev prettier-eslint ``` ## Usage ### Example ```js const format = require('prettier-eslint'); // notice, no semicolon in the original text const sourceCode = 'const {foo} = bar'; const options = { text: sourceCode, eslintConfig: { parserOptions: { ecmaVersion: 7, }, rules: { semi: ['error', 'never'], }, }, prettierOptions: { bracketSpacing: true, }, fallbackPrettierOptions: { singleQuote: false, }, }; const formatted = await format(options); // notice no semicolon in the formatted text formatted; // const { foo } = bar ``` ### options #### text (String) The source code to format. #### filePath (?String) The path of the file being formatted can be used to override `eslintConfig` (eslint will be used to find the relevant config for the file). #### eslintConfig (?Object) The config to use for formatting with ESLint. Can be overridden with `filePath`. #### prettierOptions (?Object) The options to pass for formatting with `prettier`. If not provided, `prettier-eslint` will attempt to create the options based on the `eslintConfig` (whether that's provided or derived via `filePath`). You can also provide _some_ of the options and have the remaining options derived via your eslint config. This is useful for options like `parser`. **NOTE:** these options _override_ the eslint config. If you want the fallback options to be used only in the case that the rule cannot be inferred from eslint, see "fallbackPrettierOptions" below. #### fallbackPrettierOptions (?Object) The options to pass for formatting with `prettier` if `prettier-eslint` is not able to create the options based on the the `eslintConfig` (whether that's provided or derived via `filePath`). These options will only be used in the case that the corresponding eslint rule cannot be found and the prettier option has not been manually defined in `prettierOptions`. If the fallback is not given, `prettier-eslint` will just use the default `prettier` value in this scenario. #### logLevel (?Enum: ['trace', 'debug', 'info', 'warn', 'error', 'silent']) `prettier-eslint` does quite a bit of logging if you want it to. Pass this to set the number of logs you want to see. Default is `process.env.LOG_LEVEL || 'warn'`. #### eslintPath (?String) By default, `prettier-eslint` will try to find the relevant `eslint` (and `prettier`) module based on the `filePath`. If it cannot find one, then it will use the version that `prettier-eslint` has installed locally. If you'd like to specify a path to the `eslint` module you would like to have `prettier-eslint` use, then you can provide the full path to it with the `eslintPath` option. #### prettierPath (?String) This is basically the same as `eslintPath` except for the `prettier` module. #### prettierLast (?Boolean) By default, `prettier-eslint` will run `prettier` first, then `eslint --fix`. This is great if you want to use `prettier`, but override some of the styles you don't like using `eslint --fix`. An alternative approach is to use different tools for different concerns. If you provide `prettierLast: true`, it will run `eslint --fix` first, then `prettier`. This allows you to use `eslint` to look for bugs and/or bad practices, and use `prettier` to enforce code style. ### throws `prettier-eslint` will **only** propagate _parsing_ errors when either `prettier` or `eslint` fails. In addition to propagating the errors, it will also log a specific message indicating what it was doing at the time of the failure. **Note:** `format` will not show any message regarding broken rules in either `prettier` or `eslint`. ## Capturing ESLint messages ```js const { analyze } = require('prettier-eslint'); const text = 'var x = 0;'; const result = await analyze({ text, eslintConfig: { rules: { 'no-var': 'error' }, }, }); console.log(result.messages); ``` produces on the console ``` [{ ruleId: 'no-var', severity: 2, message: 'Unexpected var, use let or const instead.', line: 1, column: 1, nodeType: 'VariableDeclaration', messageId: 'unexpectedVar', endLine: 1, endColumn: 11 }] ``` The additional export `analyze` is identical to `format` except that it returns a simple object with properties `output` giving the exact string that `format` would return, and `messages` giving the array of message descriptions (with the structure shown above) produced by the `eslint` analysis of the code. You may use `analyze` in place of `format` if you would like to perform the formatting but also capture any errors that `eslint` may notice. ## Technical details > Code ➡️ `prettier` ➡️ `eslint --fix` ➡️ Formatted Code ✨ ### inferring prettierOptions via eslintConfig The `eslintConfig` and `prettierOptions` can each be provided as an argument. If the `eslintConfig` is not provided, then `prettier-eslint` will look for them based on the `fileName` (if no `fileName` is provided then it uses `process.cwd()`). Once `prettier-eslint` has found the `eslintConfig`, the `prettierOptions` are inferred from the `eslintConfig`. If some of the `prettierOptions` have already been provided, then `prettier-eslint` will only infer the remaining options. This inference happens in `src/utils.js`. **An important thing to note** about this inference is that it may not support your specific eslint config. So you'll want to check `src/utils.js` to see how the inference is done for each option (what rule(s) are referenced, etc.) and [make a pull request][prs] if your configuration is supported. **Defaults** if you have all of the relevant ESLint rules disabled (or have ESLint disabled entirely via `/* eslint-disable */` then prettier options will fall back to the `prettier` defaults: ```js { printWidth: 80, tabWidth: 2, singleQuote: false, trailingComma: 'none', bracketSpacing: true, semi: true, useTabs: false, // prettier-eslint doesn't currently support // inferring these two (Pull Requests welcome): parser: 'babylon', bracketSameLine: false, } ``` ## Troubleshooting ### debugging issues There is a lot of logging available with `prettier-eslint`. When debugging, you can use one of the [`logLevel`](#loglevel-enum-trace-debug-info-warn-error-silent)s to get a better idea of what's going on. If you're using `prettier-eslint-cli` then you can use the `--log-level trace`, if you're using [the Atom plugin][atom-plugin], then you can [open the developer tools][atom-dev-tools] and enter: `process.env.LOG_LEVEL = 'trace'` in the console, then run the format. You'll see a bunch of logs that should help you determine whether the problem is `prettier`, `eslint --fix`, how `prettier-eslint` infers your `prettier` options, or any number of other things. You will be asked to do this before filing issues, so please do :smile: > NOTE: When you're doing this, it's recommended that you only run this on a > single file because there are a LOT of logs :) ### eslint-disable-line While using `// eslint-disable-line`, sometimes you may get linting errors after the code has been processed by this module. That is because `prettier` changes this: ```js // prettier-ignore if (x) { // eslint-disable-line } ``` to this: ```js if (x) { // eslint-disable-line } ``` And the `eslint --fix` wont change it back. You can notice that `// eslint-disable-line` has moved to a new line. To work around this issue, you can use `//eslint-disable-next-line` instead of `// eslint-disable-line` like this: ```js // eslint-disable-next-line if (x) { } ``` ## Inspiration - [`prettier`][prettier] - [`eslint`][eslint] ## Other Solutions None that I'm aware of. Feel free to file a PR if you know of any other solutions. ## Related - [`prettier-eslint-cli`](https://github.com/prettier/prettier-eslint-cli) - Command Line Interface - [`prettier-atom`][atom-plugin] - Atom plugin (check the "ESlint integration" checkbox in settings) - [`vs-code-prettier-eslint`][vscode-plugin] - Visual Studio Code plugin - [`eslint-plugin-prettier`](https://github.com/prettier/eslint-plugin-prettier) - ESLint plugin. While `prettier-eslint` uses `eslint --fix` to change the output of `prettier`, `eslint-plugin-prettier` keeps the `prettier` output as-is and integrates it with the regular ESLint workflow. - [`prettier-eslint-webpack-plugin`](https://github.com/danielterwiel/prettier-eslint-webpack-plugin) - Prettier ESlint Webpack Plugin ## Contributors Thanks goes to these people ([emoji key][emojis]):