The format-all package has reached a stable state where it is apparently useful and reliable, but is not getting any new features.
I have written and maintained it from a conservative mindset. It should not do anything unexpected, and it should be as neutral and straightforward as possible, deferring all decisions to the formatters. When there are problems with particular formatters, I have tried hard to avoid adding hacks to format-all, instead asking formatter authors to fix the problems upstream. (This has generally worked well -- the authors have been very helpful.)
Upon reflection, I'd like to release a version 1.0 of format-all and freeze the current feature set. Only new formatters and bugfixes would be committed in the future. No new features.
The open PRs and issues tend to turn the package away from its conservative direction. This is a fine thing to want -- I empathize with the desire for comfort and convenience instead of simplicity. Many people are now using the apheleia package, which has taken a much more liberal approach. That's fine. I recommend that people who want more convenience use apheleia.
In case people want to take format-all itself in a more liberal direction, I am not against it, but I'd like to ask people to fork and rename the package. A package with the name "format-all" should remain on MELPA and should follow the current conservative approach that people have come to expect. That being said, apheleia is already a liberal formatting package with good traction. It's probably wiser to contribute to it than to create yet another package.
The long term
Ultimately neither format-all nor apheleia answers the big questions about formatter unification. There should be a standard way to specify settings for all formatters. A project should have one standard configuration file in which all its formatter settings are given. There should not have to be formatter-specific or editor-specific files, each with a different syntax and different quirks. Formatters should also conform to a standard command line interface so that a text editor can send its current configuration to a formatter without using a configuration file as a middle-man. Temporary files always cause trouble eventually.
These are hard problems, but it's ultimately necessary to solve them in order for us to have a seamless workflow across a wide range of formatters and editors. The solution needs to be a standard. Before formatters widely implement this standard, we could have a lightweight adapter program that is called by text editors instead of calling formatters directly. The adapter program would contain a database of each formatter's quirks, and would translate from the standard command line interface and the standard configuration options into each formatter's native quirks.
The Unibeautify project takes a stab at this problem, providing such an adapter with an admirable range of formatter support and a good-looking website. But it is not a standard, and its adapters are not especially portable or lightweight. It depends on NodeJS and for each formatter there is a separate Node module with many dependencies. On the Emacs side, reformatter.el follows a similar separation of concerns: the editor support for each language defines how to call formatters of that language.
I do not believe that's the right approach to the problem. The domain knowledge should be pooled in one place instead of being spread out across many modules written in many programming languages. The problems with that approach are already apparent: the various modules are hard to find and the domain knowledge embedded in them is hard to port across editors.
Instead, there should be one git repo with a database covering all the quirks of different formatters and languages. People would then be free to write adapter programs in whatever programming languages they want. The adapter programs would all use the knowledge encoded in the shared database, benefiting from each update to the database.
This is something that I could prototype, but it would take more time than I have in the near future. It will also not be very useful unless a standard eventually emerges. The social agreement to create a standard and follow it is as important as the technical side of the problem. Unibeautify's existing work in mapping out formatter options into one configuration file would probably be the best starting point for drafting a standard. But the will has to be there first.
The near future
The format-all package has reached a stable state where it is apparently useful and reliable, but is not getting any new features.
I have written and maintained it from a conservative mindset. It should not do anything unexpected, and it should be as neutral and straightforward as possible, deferring all decisions to the formatters. When there are problems with particular formatters, I have tried hard to avoid adding hacks to format-all, instead asking formatter authors to fix the problems upstream. (This has generally worked well -- the authors have been very helpful.)
Upon reflection, I'd like to release a version 1.0 of format-all and freeze the current feature set. Only new formatters and bugfixes would be committed in the future. No new features.
The open PRs and issues tend to turn the package away from its conservative direction. This is a fine thing to want -- I empathize with the desire for comfort and convenience instead of simplicity. Many people are now using the apheleia package, which has taken a much more liberal approach. That's fine. I recommend that people who want more convenience use apheleia.
In case people want to take format-all itself in a more liberal direction, I am not against it, but I'd like to ask people to fork and rename the package. A package with the name "format-all" should remain on MELPA and should follow the current conservative approach that people have come to expect. That being said, apheleia is already a liberal formatting package with good traction. It's probably wiser to contribute to it than to create yet another package.
The long term
Ultimately neither format-all nor apheleia answers the big questions about formatter unification. There should be a standard way to specify settings for all formatters. A project should have one standard configuration file in which all its formatter settings are given. There should not have to be formatter-specific or editor-specific files, each with a different syntax and different quirks. Formatters should also conform to a standard command line interface so that a text editor can send its current configuration to a formatter without using a configuration file as a middle-man. Temporary files always cause trouble eventually.
These are hard problems, but it's ultimately necessary to solve them in order for us to have a seamless workflow across a wide range of formatters and editors. The solution needs to be a standard. Before formatters widely implement this standard, we could have a lightweight adapter program that is called by text editors instead of calling formatters directly. The adapter program would contain a database of each formatter's quirks, and would translate from the standard command line interface and the standard configuration options into each formatter's native quirks.
The Unibeautify project takes a stab at this problem, providing such an adapter with an admirable range of formatter support and a good-looking website. But it is not a standard, and its adapters are not especially portable or lightweight. It depends on NodeJS and for each formatter there is a separate Node module with many dependencies. On the Emacs side, reformatter.el follows a similar separation of concerns: the editor support for each language defines how to call formatters of that language.
I do not believe that's the right approach to the problem. The domain knowledge should be pooled in one place instead of being spread out across many modules written in many programming languages. The problems with that approach are already apparent: the various modules are hard to find and the domain knowledge embedded in them is hard to port across editors.
Instead, there should be one git repo with a database covering all the quirks of different formatters and languages. People would then be free to write adapter programs in whatever programming languages they want. The adapter programs would all use the knowledge encoded in the shared database, benefiting from each update to the database.
This is something that I could prototype, but it would take more time than I have in the near future. It will also not be very useful unless a standard eventually emerges. The social agreement to create a standard and follow it is as important as the technical side of the problem. Unibeautify's existing work in mapping out formatter options into one configuration file would probably be the best starting point for drafting a standard. But the will has to be there first.