Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resolve conflicts with arrow-body-style(and other rules) #383

Open
fisker opened this issue Feb 2, 2021 · 3 comments
Open

Resolve conflicts with arrow-body-style(and other rules) #383

fisker opened this issue Feb 2, 2021 · 3 comments

Comments

@fisker
Copy link
Member

fisker commented Feb 2, 2021

To resolve this problem, all we have to do is protect our fix "range", so other rules won't do fix inside it.

  • Question: how wide should our range be, the whole file or the max diff range. I've draft Fix conflicts with arrow-body-style #379 to protect whole file.
  • Impact: This will slow down eslint fix, ESLint takes up to 10 rounds to run rules, in the round of prettier/prettier other rule won't work.
  • Problem: We don't want report issues on whole file, but we can still report each difference but fix the whole file, use ESLint through CLI won't feel anything, but if running in editor, people may don't expect that happen. I got no good solution, in Fix conflicts with arrow-body-style #379 I added a notice behind the error message, and to fix one difference I used suggestion API.

I'd like to ship this feature under "experimentalFix" flag first.

Another alternative solution #381 is protect whole file on every fix of difference, but this will takes many rounds to fix the whole file, seems unacceptable solution.

Thoughts?

@devinrhode2
Copy link

Maybe a totally different approach would be to try and bake these rules directly into prettier. I think it might start to break prettier's philosophy, but, the options could be un-documented and only available through a "secret" hatch if you will. (Probably just exposed when you run require('prettier')). I wonder if there could be an alternate prettier plugin. Plugins are typically used for supporting different languages (ruby, elm, etc) but it's one possible vector.

@devinrhode2
Copy link

Turns out that even stacking eslint on top of prettier, eslint does not know how to even maintain prettier's formatting:

I tried to get eslint and prettier to play nice inside of vscode... but when I save the first return-less snippet of code, I'm getting this:

CleanShot 2022-07-19 at 12 26 01

Second time I save it.. eslint has nothing to do, prettier does a final fix to the formatting:
CleanShot 2022-07-19 at 12 27 18

Using this vscode extension: prettier/prettier-vscode#1555 rohit-gohri.format-code-action

here's relelvant .vscode/settings.json:

  // By default, format code with prettier onSave:
  //  (Currently, this mostly just handles markdown files and json files)
  "editor.formatOnSave": true,
  "editor.defaultFormatter": "esbenp.prettier-vscode",

  // Enable eslint vscode extension:
  "eslint.enable": true,
  "eslint.format.enable": false, // assert default
  "eslint.validate": [
    "javascript",
    "javascriptreact",
    "typescript",
    "typescriptreact"
  ],
  "prettier.useEditorConfig": true,
  "eslint.useESLintClass": true,
  "eslint.packageManager": "yarn",
  "eslint.probe": [],
  "[typescript]": {
    "editor.formatOnSave": false,
    "editor.codeActionsOnSave": [
      "source.formatDocument",
      "source.fixAll.eslint"

@JounQin
Copy link
Member

JounQin commented Jul 19, 2022

You should turn off the conflict rule for now and try to reload vscode after eslint/preittier config changed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants
@fisker @devinrhode2 @JounQin and others