Separate beautifier packages from core

[jcartledge]

I know you've expressed in #320 that you're not keen to do this, but I'd like to make the case for it again.

The primary reason from my point of view is the UX of the config screen.

There are several screens of options, most for languages/beautifiers I don't use, all with equal visual weight and no clear separation.

If you have multiple beautifiers for a language there's no way of only showing (or highlighting) the options related to the selected beautifier.

This is really poor UX, and it's a direct consequence of keeping everything in one plugin.

Taking a modular/framework approach similar to the linter project would address these shortcomings and allow people to only install (and maintain config for) beautifiers they use, while ensuring consistent UX.

This would also allow developers to easily create and publish new beautifiers without requiring a PR and a new release of the core project.

Issues would get tracked against the specific beautifier/language plugin and could be handled by plugin maintainers - again, with their own upgrade/release cycle separate from core.

I started to look at adding a second beautifier for PHP using PHPCBF but because of the issues above decided to make it stand-alone (https://atom.io/packages/phpcbf). I'd love to provide it as part of a beautifier ecosystem as I think that's the best outcome for users.

Is there any way you can see this happening? What support would you need from contributors to do this?

[Glavin001]

The primary reason from my point of view is the UX of the config screen.

There are several screens of options, most for languages/beautifiers I don't use, all with equal visual weight and no clear separation.

If you have multiple beautifiers for a language there's no way of only showing (or highlighting) the options related to the selected beautifier.

This is really poor UX, and it's a direct consequence of keeping everything in one plugin.

This could be improved from within Atom's Settings View. There should be searching and collapsable sections, such that packages like Atom Beautify could group similar options and hide them until the User wishes to see them.

I recommend making an issue with them. If such a feature existed in Settings View then Atom Beautify could quickly adopt it and organize the options for improved UX.

This would also allow developers to easily create and publish new beautifiers without requiring a PR and a new release of the core project.
...
Issues would get tracked against the specific beautifier/language plugin and could be handled by plugin maintainers - again, with their own upgrade/release cycle separate from core.

These are worthwhile advantages.

Is there any way you can see this happening? What support would you need from contributors to do this?

I can see it potentially happening, however I am currently unavailable to do the major work that would be required for this move.

I also do not see enough of an advantage (yet) such that even if I had the time, that I would do this.

It is difficult for myself to maintain these beautifiers if this package repository breaks into potentially 23 different packages for each beautifier. See https://github.com/Glavin001/atom-beautify/tree/master/src/beautifiers
If I were to add a feature to the core that would be applied to all beautifiers I may have to update all 23 beautifiers. Right now, that involves editing 23 different files in a single repository and publishing once. If they are separate repositories then I will have to update each different repository and publish each separately. Also the language beautifier testing is currently done all at once, and this would have to be separated. I can see particular beautifier packages falling behind because of this separation, and the quality of each beautifier may fall behind others, depending on contributors.

What needs to happen

Let's say that I did want to do this, and there were sufficient advantages that would make it worthwhile to put the time in.
I would definitely need contributors to help me design and develop this. Atom Beautify has been through multiple, major internal implementation changes and I am confident we could make this work and appear seamless to the many users who depend on Atom Beautify. In fact, I think we could have v1.0.0 be an update that would implement this separated repository idea and the users would not experience any breaking changes, if we executed it properly.

Version 1.0.0

Off the top of my head, here are some ideas for v1.0.0, some of which are applicable to this issue.

Items marked with *: This would be critical for separating Atom Beautify into the other 23+ repositories for each of the beautifiers

• * I would want the beautification core to know all of the available languages that are supported and their potential beautifiers
  • Thus when a user installs Atom Beautify and were to run beautify command on a file, since they have not installed atom-beautify-javascript for instance it would actually notify the user and recommend that they install atom-beautify-javascript. I want this to be automatic. The idea that the beautifiers are stored in separate repositories should be abstracted from the users. They want to beautify this file, make it happen, install everything that is necessary, etc.
• * Significant refactoring of the code base to use Atom's Services API. See https://atom.io/docs/v1.0.19/behind-atom-interacting-with-other-packages-via-services
• Separate Processes all for Beautifiers
  • Beautifiers written in Node.js are called directly within Atom Beautify. Some of these beautifiers can be blocking. I want to remove all blocking code. All Node.js beautifiers should be spawned into separate processes that pass messages to communicate and run asynchronously to each other.
• Parallelism
  • For Beautify selected directory? #120 I investigated the idea of beautifying entire directories of files. With all beautifiers being separate processes and running independently of each other, this could dramatically improve performance of bulk beautification requests
  • We could also have beautifier process pools

Thank you for your feedback. I hope we can work together to design and develop the next version of Atom Beautify.

[aidistan]

I like this idea and want to be part of this.

In fact, I think we could have v1.0.0 be an update that would implement this separated repository idea and the users would not experience any breaking changes, if we executed it properly.

It's good if we can do this. But if not, I think it's okay to rename atom-beautify v1.x to something else, like beautifier (yeah, it isn't taken yet), and put the core package and other beautifier packages under AtomBeautifier, just like AtomLinter.

In addition, I think we should also support following features (all in v1.0.0 milestone already):

• dynamic beautifier (Dynamic beautifier per project #1041)
• multiple/cascade beautifier (Multiple active beautifiers per language #457)

What concerns me most is that #716 is still in progressing, and seems to become the blocking issue to the entire millstone.

[raphinesse]

@Glavin001 I see the biggest advantage in a leaner package itself. If users only install what they need, it will improve:

• Disk space usage
• Frequency of update prompts
• Update durations
• Startup performance
• And of course maintainability for both the users (settings etc.) and the developers (division of labor, separation of concerns, divide and conquer, blah blah...)

The current state of all of the above points combined has bothered me to the point that I have uninstalled atom-beautify at last. I'd love to come back to it when I can choose only what I need and thusly have a leaner installation.