Use prettier-eslint defaults when installed in project

As promised, making my case from my assertion in #216. If the concept is approved, and nobody is too antsy to wait for me to get around to implementing it, I’m willing to put in the work to make it happen.

---

Right now, using prettier-eslint and eslintConfig is the only way to configure what prettier-atom will do for a project, so it applies to all users of that codebase. Prettier unfortunately loses most of its value if it’s not being used consistently across all contributors to a project, unless it’s not being enforced by the project at all.

To that end, it’s my belief that when the eslint integration is enabled, and is actually installed in the project, the only consistent thing to do would be to use the fallback values defined by prettier-eslint. I think that even the eslint integration would ideally be enabled automatically in prettier-atom if it’s being used by project (noticed by pretter-eslint or prettier-eslint-cli being installed).

Looking around, I see that there are issues open regarding adding a prettier config file. When that happens, that of course would be a better setting to use as fallbacks, but I’m sure that prettier-eslint will use that as it’s fallback instead, meaning that the fallback would still not be implemented by prettier-atom.

That leaves the settings, ideally, as only being used when there is no other configuration, expressed or implied, given by the project. Anything else makes it difficult to use a shared style through prettier.

---

In early issues on this front from the prettier repo, the thought was that the editor should reflect the user’s preferences, while the saved files should be able to enforce the project’s preferences. That’s a very interesting idea, but if that’s not done, it would be far better to use the project’s preferences in the editor, than to default in whole, or especially in part, to the user’s preferences.

[olsonpm]

Or more accurately, the prettier config isn’t necessary either. I think it should be keyed on whether or not it’s in the package.json, since the project may be perfectly happy with the all of the defaults of prettier

I just want to clarify one difference in the implementation that we’ve landed on over what OP expected above.

Since it’s reasonable for a project to list prettier as a dependency without actually wanting it to format their codebase, I think a configuration is a non-ambiguous heuristic for “intent to format”. If a project wants all defaults they should list an empty config.

This is the condition #374 uses when deciding whether to pass any prettier-atom settings onto prettier.

[robwise]

Yeah, what I’m envisioning code-wise to get this done would be a change that would work regardless of whether the user is using prettier-eslint or not. Basically, if we detect that prettier is in the package.json and this option is enabled, we just don’t pass any options from prettier-atom. That’s really all, it would be a pretty simple change I think.