Allow easier integration with tools like eslint

This is coming from https://github.com/jlongster/prettier/issues/40#issuecomment-272360783

Right now we take an input string and return an output string. The problem is that if anyone wants to integrate with other tools that deal with ASTs, they will have to parse the string again. For large files this performance hit is not really acceptable.

A very common case will probably be eslint. I’d like to make sure we provide the right APIs to make it easy to integrate with tools like that.

Regarding eslint: there are 2 things it does. It has semantic rules that can be checked given an AST (the actual formatting doesn’t matter). It also has formatting rules, which can fixed automatically with --fix. These are two very different use cases and I’m mostly thinking of the former. It seems like the only reason people would want to pass the output of prettier into eslint is to drop semicolons. If people want to use eslint’s formatting options, it’ll have to double-parse because we need to print first and then it needs to parse the output. Then people could use --fix to tweak the output (this seems like a pretty convoluted/slow process though).

For all the semantic checking, I should be able to pass my AST into eslint first, and then print it afterwards, which is the other way around. @hzoo can eslint fix any of the semantic rules? If so, how does it do it? Does it edit the AST in place, create a new AST, etc?

I think all we need to do is introduce a new API method: formatAST. This would take an AST instead of a string. This would allow people to use other parsers (if available), do any AST wrangling beforehand, and just give it to us. It’s much more performant than generating the string and then us parsing it again.

This allows integration with any other tooling that deals with ASTs, and it’s up the editor plugin to do that integration.

[robwise]

From https://github.com/jlongster/prettier/issues/296#issuecomment-273601563 from @jlongster:

I don’t recommend using this [Prettier] with eslint’s formatting rules. You should get rid of the formatting rules and keep the other rules that enforce semantic behaviors.

If a developer configures eslint’s formatting rules to mirror what Prettier is outputting anyway, then what is the argument against leaving those rules enabled? That way, CI and editors with linter integration can enforce Prettier’s style (in case a developer isn’t using format-on-save and forgot to format their code or something).

What’s more, in those cases where their eslint rules conflict with Prettier’s style in a way that isn’t configurable, if the rules in question are eslint-auto-fixable, they can still benefit from Prettier by running Prettier first and eslint second.

Which brings me to my point: I strongly believe that Prettier should be configurable enough that it won’t force people to go against https://github.com/airbnb/javascript. It’s got almost 46,000 stars and has gone a long way towards promoting a consistent DX across projects.

If this would require a massive amount of work, maybe it would be a gray area given your vision of an opinionated, convention-over-configuration type tool. However, if we limit the changes to those Prettier rules that are incompatible with that project and that aren’t Prettier-configurable and aren’t eslint-auto-fixable, there aren’t that many:

• Airbnb/javascript wants parentheses around ternaries but Prettier removes them
• ~Airbnb/javascript has spaces in curly braces but no spaces in straight brackets but Prettier doesn’t differentiate between the two; it’s either both have spaces or neither have spaces~ (eslint auto-fixes this)

Although I admit I probably have not yet discovered all of the conflicts yet, so far there aren’t a huge amount of changes required to make Prettier 100% compatible the eslint airbnb/javscript preset assuming eslint-auto-fix is on and run afterwards.

Here is an example of using Prettier first and then eslint afterwards where I am missing some trailing commas and also Prettier is putting spaces in the square brackets, and then eslint autofixes them back so it’s happy in the end:

[vjeux]

We’re good on this front, people have created the plugins and we are featuring them on the README 😃