Request: respect Prettier default settings

[papb]

XO infers rules from prettier in a way that I don't think is the best. From readme:

prettier

[...]

[...] and if not set will be determined as follow:

• semi: based on semicolon option
• useTabs: based on space option
• tabWidth: based on space option
• trailingComma: none
• singleQuote: true
• bracketSpacing: false
• jsxBracketSameLine: false

I think that trailingComma, singleQuote, bracketSpacing and jsxBracketSameLine should pick the same defaults from Prettier instead of having another predefined default choice made by xo.

The current behavior caused some confusion to me and someone else in #440.

[fregante]

You're using eslint and prettier through XO, it makes complete sense that both of them follow XO’s style, not the other way around, otherwise there's no point in running Prettier through XO.

If you prefer Prettier’s defaults, use xo && prettier .

[KaiSchwarz-cnic]

I personally don't agree to @fregante. Prettier is maybe the best formatter available, still - and that's brought up in the prettier docs, it makes sense to use linters - just for the static code analysis part. This finally means that linters have then to be reconfigured to follow prettiers style configuration. In addition, people have prettier often running locally (format on save), but linters running in their CI. So xo && prettier makes no sense in that scenario. We also use exactly this setup, so prettier with xo, htmllint, stylelint, etc. Working great. I am understanding your approach with xo && prettier, no question - but this is then not considering the configuration setting prettier: true - the reason for this gh issue.

We just noticed that xo does not consider prettiers defaults even though prettier: true is set in case no configuration file is present for prettier (or if present, missing rules might still fallback to xo's defaults - I've not tested this). This is well documented in the docs as described by @papb. Instead of falling back to these defaults which do not fit to the prettier defaults, why not looking the defaults dynamically up from prettier module itself - as reported by @papb this leads just to confusion (including myself)? pkg prettier-default-config could be used for that or just follow their approach: https://git.simulacrum.party/simulacrumparty/prettier-default-config/src/branch/master/index.js#L12

We fixed this by defining a .prettierrc.js with specifying all default values we found in the prettier docs, here.

module.exports = {
  printWidth: 80,
  tabWidth: 2,
  semi: true,
  singleQuote: false,
  quoteProps: "as-needed",
  jsxSingleQuote: false,
  trailingComma: "es5",
  bracketSpacing: true,
  jsxBracketSameLine: false,
  arrowParens: "always",
  requirePragma: false,
  insertPragma: false,
  useTabs: false,
  proseWrap: "preserve",
  htmlWhitespaceSensitivity: "css",
  vueIndentScriptAndStyle: false,
  endOfLine: "lf",
  embeddedLanguageFormatting: "auto",
  rangeStart: 0,
  rangeEnd: Number.POSITIVE_INFINITY,
};

This works great, but still, if they add/change options in prettier we will have to update our configuration again. That's why having xo falling back to prettier defaults dynamically as described would be really great.

Just my 2 cents.

TBH I couldn't follow your thoughts fregante You're using eslint and prettier through XO. XO is wrapping eslint - offering less configuration effort. So, basically we could also just speak of somehow using prettier and eslint together. I guess the reported and well described scenario, which is even part of the prettier official docs, makes definitely sense to consider.

@Rashad-j fyi

In addition, and that's maybe the more useful part for XO itself: Why not having a configuration flag noStyleChecks: true, to completely deactivate format/style checks. That would be helpful to support ANY formatter and such a scenario the best, not just prettier. So, also save for future tools. it would also allow to deprecated the prettier option. In that way XO could still be used as static code analysis tool.

[KaiSchwarz-cnic]

... and for the other way around, when thinking about the prettier: true setting when just using xo standalone - still anyone would expect that xo would then follow prettier configuration settings. If not set, fallback to prettier defaults - as by that configuration setting, prettier styling is the desired output and behavior. If just a subset of prettier configurations is set, for the other settings (the one who are left out) I would also expect the prettier defaults to used then.

Also here, it might be worth to again point to the idea of a configuration option "noStyleChecks" as perfect solution to separate styling checks and static code analysis checks, but yes, it is then no longer about using xo standalone. But, do you plan to keep adding further formatters as dependencies of xo and further flags like prettier in future? I guess, rethinking here is definitely worth it to introduce a perfect compatibility with any existing or future formatter.

Finally, I guess this then also depends on eslint iself supporting such a possibility. :-)