Here's an example of Nuclide's JSON formatting using this service

i'm confused at what you're proposing. It doesn't make sense to me to couple this plugin with atom ide, but if there's something this plugin can do to make it easier for atom-ide to consume it then that would make sense to me.

Yep, all that's needed is providing an Atom service or two the same way the above JSON formatter does. The service boundary keeps things neatly decoupled.

Description is here and docs are here

I see - thanks for the links. I didn't know atom had a service api that you could declare in the package.json like that. Seems pretty cool. I'm a new collaborator and wouldn't be the one to okay something like this since it does take on extra maintenance, but it's got my 👍

Is there prior art with there being extension plugins for Atom IDE, or is it expected that packages expose hooks for Atom IDE?

I'm hesitant to add more complexity to support a non-standard Atom work environment. As much as I love what Atom IDE is doing (I presently use Nuclide), I'm not convinced it would be our responsibility to provide support. Can you provided non-Nuclide examples (since Atom IDE was born out of Nuclide)?

my understanding is that packages expose services via atom's service api. It just so happens that atom-ide is the one defining and reading from those services. We would only be importing atom-ide if we wnted to type check our service structure.

without implementing it's hard to know exactly the complexity added, but it didn't seem much. However it would be supporting a new endpoint into the plugin so i think the maintenance is a valid concern.

Looking at the provided documentation it seems almost too easy, which is why I'm skeptical. Haha. What are your thoughts on this @robwise?

I'd be fine with doing this, I use atom-ide so at least one of us would be already set up to mess with it and test bugs. My only question is if we expose this to atom-ide so that it can format on save, then do we need to turn the normal format on save?

Not sure what you mean by "the normal format on save".

Anywhoo @wbinnssmith seems you're good to start on a PR when you feel it. You can ping me if you have questions about the code.

This change would expose a new, other format-on-save functionality that can be turned on in atom-ide's settings. This would be in addition to the existing format-on-save functionality we've always had in this package, which I'm referring to as the "normal" format-on-save.

Is it going to double format-on-save? When I save a file, atom-ide will detect it and invoke format-on-save in all of the services offering that functionality which, if we implement this, would include us. So prettier gets invoked from atom-ide. However, we're also watching for a file being saved directly ourselves, and this would format-on-save as well. This is the normal format-on-save.

When using prettier-atom with atom-ide, I also noticed that atom-ide interacts with the diagnostics area of the editor and will complain about linter being installed. You're forced to choose between linter and atom-ide's own package. I'm unsure of whether prettier-atom and atom-ide play super well together, at the moment.

You can ignore prettier-atom's dependency on linter and still get the format on save features, but likely at the cost of the eslint-specific stuff.

@ryancole prettier-atom is fully compatible with atom-ide when it comes to diagnostics instead of linter. atom-ide was written so that any package that uses the linter package automatically works with atom-ide instead. If you're using atom-ide, then disable the linter package. You will still get full functionality from prettier-atom as everything we try to send to linter gets automatically picked up by diagnostics instead.