Given that parsing (and formatting) Haskell code tends to need information that is not lexically available, such as the fixity of operators imported from libraries or extensions enabled in cabal files or elsewhere, my natural inclination to have robust formatting would be to put it into intero, or ghc-mod, or haskell-ide-engine or whatever is the backend-du-jour.

Naturally, ormolu stands as a stand-alone tool like hindent and that's fine, but if it exposes a relatively simple Haskell API, then it can be imported by e.g. intero; Intero would parse the module itself using the proper flags and context, and it would pass the parsed AST over to ormolu.

Obviously, to be robust on "Real" code, you need to handle CPP to some degree like hindent tries to do. A user would want Ormolu to reformat with CPP taken into account, which is hard to do completely but doable in part. So that would be something to think about.

I've seen that the ormolu function already accepts a Located (HsModule GhcPs) via parseModule', so it might just be a case of exposing the right fragment of the ormolu function.

If you're in agreement with this as a side-goal, I could pretty easily take a crack at importing ormolu from intero with a :format command (or so) and then open a PR here for scrutiny of what'd be necessary to expose in ormolu for an IDE backend to use it. You guys wouldn't necessarily have to do any work in the end.

One soft-requirement for intero is light dependency footprint (so that it's easy and fairly fast to install for users), and ormolu's dependencies are quite light at the moment, which is good. yaml does bring a big footprint, but maybe that could be disabled with a flag. 🤔 Not sure. Technically people only need to install intero per GHC version nowadays, so it's less of a requirement. But I already regret adding the network dependency to intero, so... That's a delicate topic.