prettier-vscode: [BUG] not working with eslint 6

running "prettier.eslintIntegration": false as a work around

any luck on this? it’s a critical issue to be honest

vscode-eslint recently suggests using editor.codeActionsOnSave, and I found it doesn’t work well with editor.formatOnSave because it runs eslint fix first then prettier. What I want is prettier then eslint fix.

Then I add editor.action.formatDocument to codeActionsOnSave and disable formatOnSave, everything works fine for me now.

This is my current config, tested on MacOS with:

VSCode: 1.41.1 prettier-vscode: 3.18.0 vscode-eslint: 2.0.11

{
  "[javascriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[typescriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "editor.formatOnSave": false,
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true,
    "editor.action.formatDocument": true
  }
}

How I’ve sorted it after having super huge frustrations with Prettier stopping working.

VS Code -> View -> Command Palette, type: Format Document With, then Configure Default Formatter... and then choose Prettier - Code formatter.

This sorted the problem for me magically. It looks that VS Code had other options for formatting not only Prettier but did not show any error or notification so you can choose from.

I hope it helps others too!

It seems like prettier-eslint is mostly a dead project so it is unlikely this will ever get fixed. I would suggest switching to the recommended approach of integrating ESLint and Prettier

@jakeleventhal I agree! I don’t see myself using this plugin without that integration.

@ntotten @asbjornh

As @ehaynes99 and @EthanNYT both mentioned, l want to still keep the functionality of having a shared eslintconfig between my Prettier and eslint CLI for running --fix.

I use airbnb as my base eslint config

It seems the only viable option is adding support for eslint 6+ This is kind of a deal breaker for me if it can’t be fixed.

to:

require /node_modules/eslint/lib/linter/index.js

Maybe change to require('node_modules/eslint/lib/linter') instead? Node’s module resolution would then check both linter.js and linter/index.js. If the import looked like that in the first place we wouldn’t have an issue now 😃

I’ve ended up removing the extension and I am using https://github.com/prettier/eslint-plugin-prettier instead.

It’s worth noting that eslint-plugin-prettier will trigger a full prettier parse and format cycle for every single file, within the existing eslint parse and lint cycle.

This means that it doubles the parsing effort done during your eslint run, on top of also having to diff and report errors on the output if it is different. If you’re running auto fixers then every fix will trigger a file change, which will trigger the eslint-plugin-prettier run (parsing the file yet again).

This can have significant impact on eslint performance compared to running the two separately, esp if you’re regularly running full lint cycles on a large codebase.

prettier-eslint is a much better solution because the file is parsed and formatted exactly once by prettier, before eslint runs - saving a lot of potential reparses and lint cycles.

@jakeleventhal If you want to use the eslint-prettier integration then, yes you would have to find a new option. If you want to use eslint with prettier the recommended way you can still use this extension - https://prettier.io/docs/en/integrating-with-linters.html

Unfortunately, with limited resources on this project maintaining the ESLint integration is not possible and my preference is to focus on improving the core features. See #922 for discussion.

I couldn’t get @kebot’s workaround to work on the latest extension and vscode versions. So I published a small extension to run ‘Format Document’ as a codeAction:

https://github.com/rohit-gohri/vscode-format-code-action/

Along with the latest VS Code update, which allows setting order of codeActionsOnSave, this removes the need for prettier-eslint to specify the order of commands in VS Code. We can use the prettier-vscode and vscode-eslint extensions separately and just define the order in vscode settings.

Example here: https://github.com/prettier/prettier-vscode/issues/1277#issuecomment-621175180

Okay, I am going to relent on this slightly. We’ll keep the integrated linters, but I am going to mark the configuration as deprecated and encourage people to move to use the alternative approaches.

We may move to remove them entirely in the future or if the bugs get fixed perhaps we can find a way to keep them.

RIP

@ntotten Essentially, that means throwing away the entire functionality of eslint --fix. I don’t see auto formatting and formatting rules to be disparate concerns. It’s worse than just having 2 configs. Prettier breaks hundreds of eslint rules, including some found in all 3 of the major eslint presets. You have to pick one or the other.

https://github.com/prettier/eslint-config-prettier claims to

let you use your favorite shareable config without letting its stylistic choices get in the way when using Prettier.

Respectfully disagree. They’re not “getting in the way”, they’re the entire purpose of a preset that has rules beyond outright syntax errors.

I want to stress that I’m not trying to be combative. This combination has been incredible, and allows me – for the first time in my entire career – to actually break builds to enforce standards. That’s just too hard a sell to the majority of dev teams if I can’t automate it.

@asbjornh Not the same thing. The config turns off eslint rules that prettier breaks. It doesn’t teach eslint to be as good as prettier at its strengths like line breaks, wrapping, nesting, etc.

Oh, this seems to be caused by a known issue with prettier-eslint (https://github.com/prettier/prettier-eslint/issues/222). I guess we’ll have to wait for them to fix that first 😃

Need this ASAP!

@ntotten There’s another project effective-prettier-vscode, which is similar to prettier-eslint. It runs prettier, then eslint, then stylelint:

https://marketplace.visualstudio.com/items?itemName=sebastian-software.effective-prettier-vscode

https://github.com/sebastian-software/effective-prettier https://github.com/sebastian-software/effective-prettier-vscode

yarn add --dev @effective/prettier

In .code-workspace:

"editor.defaultFormatter": "sebastian-software.effective-prettier-vscode"

Switched to it today because prettier-eslint stopped working, works well so far.

Same problem with 3.11.0 here.

@ntotten I don’t want two separate configs though. It’s nice to define linting and formatting rules in my ESLint config and have Prettier interpret them from there.

I tried creating a fresh project to reproduce, and I’m now getting a different error message:

Failed to load plugin 'prettier' declared in 'CLIOptions'<project-path>/index.js:: Cannot find module 'eslint-plugin-prettier'
Require stack:
- /__placeholder__.js

eslint-plugin-prettier is most definitely installed. For anyone interested in debugging this, here is a setup for reproducing this:

  "dependencies": {
    "eslint": "^6.1.0",
    "eslint-config-prettier": "^6.0.0",
    "eslint-plugin-prettier": "^3.1.0",
    "prettier": "^1.18.2"
  }

eslintrc:

{
  "plugins": ["prettier"],
  "extends": ["prettier"],
  "rules": {
    "prettier/prettier": ["warn"]
  }
}

Running with prettier.eslintIntegration: true and selecting Format Document With from the command palette in an empty js file should result in the above error message.

Auto format on save suddenly NOT WORK in recent days, I have to format document with keyboard 😦 Uninstall vscode-eslint fixed auto format on save issue!

3.6.0 and 3.7.0 are ok! But it seems like the same problem is back in 3.8.0 today. Or even a similar problem.

Can you guys take a look?

Output with 3.6.0 and 3.7.0:

[INFO - 2:02:11 PM] Prettier Options:
{
  "arrowParens": "avoid",
  "bracketSpacing": true,
  "endOfLine": "auto",
  "htmlWhitespaceSensitivity": "css",
  "insertPragma": false,
  "jsxBracketSameLine": false,
  "jsxSingleQuote": true,
  "printWidth": 120,
  "proseWrap": "preserve",
  "quoteProps": "as-needed",
  "requirePragma": false,
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "none",
  "useTabs": false,
  "vueIndentScriptAndStyle": false,
  "filepath": "c:\\somefile.ts",
  "parser": "typescript"
}

Output with 3.8.0:

[INFO - 1:54:38 PM] Prettier Options:
    {
      "filepath": "c:\\somefime.ts",
      "parser": "typescript",
      "useTabs": false,
      "tabWidth": 2
    }

Until this is fixed in the extension if anyone is relying on the eslint-vscode extension and wishes to setup a keybinding to “format” (well, fixing with eslint, but in most cases it’s formatting anyway) you could set a keybindg in your vscode with "shift+alt+f" (or whatever you wish) listening to eslint.executeAutofix

for more info about this refeer to https://github.com/Microsoft/vscode-eslint/issues/70

Here is a good article explaining the type of setup that is recommended going forward: https://dorshinar.me/linting-your-react+typescript-project-with-eslint-and-prettier

@ehaynes99 Have you taken into account https://github.com/prettier/eslint-plugin-prettier which I was under the impressions ran all the prettier formatting via eslint?

@jakeleventhal Not at all. In my experience if you use the VS Code ESLint and the VSCode Prettier extensions together you can use both for what they are made for - Prettier for formatting, ESLint for linting.

But if you have eslint-config-prettier and eslint-plugin-prettier in your eslint config, wouldn’t using the auto fix option with vscode-eslint have the same result as running prettier-vscode?

Edit: And if so, I don’t see what you’d use this plugin for if you also want to enforce formatting in a shared project