Need a way to support prettier-eslint

[aspiers]

Sometimes prettier disagrees with eslint --fix. One solution to this is https://github.com/prettier/prettier-eslint which runs eslint --fix after every prettier invocation. It would be great if this mode could support that. It would probably require use of https://github.com/mantoni/eslint_d.js, maybe by integrating with https://github.com/aaronjensen/eslintd-fix or at least using a very similar approach.

[jscheid]

Personally, I would try to remove the need for this hack in some other way, maybe by relaxing lint rules or changing the code style. (At my day job, we've been using eslint-config-prettier). Running eslint --fix after every change is going to slow things down no matter how much you optimize it.

That said, I'm happy to accept a PR that adds support for this as long as it's in line with this package's philosophy, which means:

• making a (reasonable) attempt at keeping the overhead as low as possible
• trying to make it robust, and so that it "just works", ie. with as little manual configuration and moving parts as possible
• supporting existing features, such as remote editing and the ability to sync Prettier options used to Emacs, inferring the parser from the major mode, using local packages when available.

I'm afraid this would likely rule out using eslint_d.js:

• IPC would add overhead
• people would have to install additional software
• there is an additional process and its state to worry about

prettier-eslint seems like a better option, and could maybe be changed to suit, but couldn't be used in its current form because currently:

• it creates new Pretter and Eslint instances for every formatting operation
• it force-overrides settings based on the file extension
• it doesn't have a way to return the formatting options used (eg. inferred from eslint) so we can sync them back to Emacs.

I think the cleanest solution would be the following:

1. Change prettier-eslint, or create a new packages (either from scratch or based on prettier-eslint), so that it has an API identical to Prettier's [†]
2. Change this package so that it accepts a "search path" for which Prettier-like packages to try, which could default to something like '(that-package prettier).

The advantages of this approach are:

• separation of concerns: this package stays focused on what it's good at
• consistency and simplicity: we reuse the existing mechanics for managing long-running processes, reusing instances, discovering, reporting and syncing config, etc.
• reusability: if someone wants to combine Prettier with some other post-processor, all they need to do is create another package that also augments Prettier without changing the API

[†] Except that it might support additional configuration options. Also, from this package's perspective, currently only the following two API methods would have to be implemented: formatWithCursor, resolveConfig.sync.

[aspiers]

Thanks a lot for the very detailed and carefully considered response! I agree with everything you've written. I'm not 100% convinced that prettier-eslint's current design is great - it seems like a workaround for the fact that two tools are disagreeing over style and consequently fighting over how the same file should look. eslint-config-prettier does sound like a less conflicted approach.

I won't have time to do any more on this right now, but maybe I'll be able to return to it in a while.

[jscheid]

Sounds like this is unlikely to happen, which is fine by me. I'm closing this for now.