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
prettier: true
, but no spaces inside braces: {Foo}
#614
Comments
I tried modifying the rules inside of my xo config, setting them to |
Q: Does the vscode extension support codeActionsOnSave? ===== My general thinking is that we should address this at an architectural level, so that any formatting inconsistencies are not possible. I think that prettier should run after eslint, and eslint should ignore all formatting issues. However, I would like to avoid writing eslint fixed code and then telling prettier to read from disk. Passing an ast directly to prettier would be awesome, but would be quite the undertaking. |
The biggest overhead with eslint-plugin-prettier I'm guessing is probably the generateDifferences call. I will check what the prettier.format( call is returning today |
import {Foo}
(object-curly-spacing){Foo}
@fisker I noticed you have some PRs for eslint-plugin-prettier, which fix the arrow-body-style issues Any thoughts here? My interest is in improving performance, but main issue here is the inconsistent formatting |
{Foo}
prettier: true
, but no spaces inside braces {Foo}
prettier: true
, but no spaces inside braces {Foo}
prettier: true
, but no spaces inside braces: {Foo}
If prettier is just a second final step, --fix simply needs to pass final source to prettier before writing to disk. Likewise, xo --check needs to call prettier --check |
@devinrhode2 xo is only a wrapper around eslint - prettier is only ran via eslint-plugin-prettier from xo. You can configure prettier by adding a prettier field to your package.json or a .prettierrc file, you probably get this. Yes, I don't think xo follows the same defaults as prettier itself, but xo's default prettier config does NOT conflict with the xo eslint rules. - it is kind of confusing. Best idea is to let xo manage both formatting and linting for you completely. Or turn prettier off in xo and configure prettier to manage formatting (as long as you have not set up conflicting rules) For VSCode - you should turn the prettier plugin off for typescript and javascript if you are using the xo plugin because they will conflict. The xo plugin supports formatting on save and can be set up correctly as follows: "typescript.format.enable": false, // turn off vscode defaults
"javascript.validate.enable": false,
"editor.formatOnSave": true, // turn on formatting on save
"[javascript]": {
// only ever set editor.defaultFormatter under a specific language
"editor.defaultFormatter": "samverschueren.linter-xo"
},
"[typescript]": {
"editor.defaultFormatter": "samverschueren.linter-xo"
}, I personally set up all my VSCode linting and formatting on a per language basis as shown above. Regarding performance in VSCode - I have some works in progress on the plugin and some updates and improvements will be coming for that soon, I just haven't quite had the time to finalize my WIP. |
Inside of eslint-plugin-prettier, I added log statements around the
I'm actually noticing that eslint-plugin-prettier is getting called twice for one If it's given Happening with: (Inside of eslint-plugin-prettier, I'm doing (yarn v1.22.15, node 16.10.0) (I'm hoping calling eslint-plugin-prettier twice may be intentional, due to some bugs around arrow functions, or eslint-disable~line/next-line comments) |
Also, performance inside of vscode has been great, no issues there. It's command line that is slow for me. Maybe, we don't need a pre-commit hook, but we'd still need to run I'm am thinking that inside of xo we'd somehow directly use Alternatively, |
Wow, dreams come true, prettier actually has an option FTR prettier was being provided these options:
|
In the readme, I read this to mean that if I have a prettier config file, that is the prettier config to be used:
Either it should say is something like:
Alternatively - we could simply NOT set these extra prettier defaults. |
I think most people using prettier will have their own prettier config. The |
This definitely sent me down a rabbit hole: xojs#614
I have
prettier: true
in my xo config, but, I'm seeing this formatting:This is fundamentally the "object-curly-spacing" style rule from eslint (or
@typescript-eslint/object-curly-spacing
).I see this is set inside eslint-config-xo and eslint-config-xo-typescript, to
["error", "never"]
- "never" meaning we never want spacing aroundFoo
.I confirmed this by setting
prettier: false
inside my xo config, and inside vscode, I see a warning regarding this style rule.As a sanity check, I did run prettier directly:
And it restores spaces around
Foo
, resulting in:I tried running
yarn prettier --write /full/path/to/file.ts
with multiple different prettier versions, 2.2.1, 2.3.2, 2.4.1, all of them restore spaces aroundFoo
.The text was updated successfully, but these errors were encountered: