Merge additional changes from adalinesimonian/merge-prettier-2.3.1

[adalinesimonian]

Closes #587
Closes #548
Closes #422
Closes #414

Per #569 (comment)

[adalinesimonian]

I have some concerns about priorities here, but as I will be unavailable from now until the 5th of July, I will voice my concerns if they are still relevant at that time at the earliest. I will be out on the streets working every day throughout the record-breaking heatwave we are experiencing here in Seattle to get critical supplies to people and get people to safety where possible. I will be taking a week to recover afterwards.

[brodycj]

Thanks. Yes I have been taking this work through a few too many circles and will try to bring some more forward progress.

I have been working pretty hard to keep things as clean and well tested as possible, unfortunately have sacrificed too much forward progress in the process.

[brodycj]

minor fix is needed here for consistency with existing prettierX version 0.18.x:

Suggested change

	? [ifBreak("", "("), parenSpace]
	? [ifBreak("", ["(", parenSpace])]

I will make this fix.

[brodycj]

Hello @adalinesimonian please be sure to stay safe in this hot weather, especially with the upcoming holiday!

I have been working pretty hard to rebase and clean these updates up in PR #630. I will likely merge these updates sometime tomorrow and then let the Renovate bot update as many dependencies as possible before making the release.

I am at the point where I would like to make the release over the holiday and move on. I know you have worked quite hard on this, and it has really distracted me from both free and professional software commitments over the past month.

There were a few things that I did, mostly in the CI testing, differently than how it was proposed here. But if you think I missed any important updates please feel free to raise one or more new PRs for disucssion.

And thanks again for your contribution, which I am sure will benefit many users.

[brodycj]

@adalinesimonian I hope you are safe after the heat and the long weekend!

I have incorporated most of the proposed changes in PR #630 and gave you some credit in README.md. I did solve some CI issues a different way, unfortunately might have missed some of your changes in the process. I have raised issue #636 to start tracking some followup items needed. Please DO feel free to raise another PR if you think I missed anything important.

These updates have taken me almost a whole month to incorporate due to the work that I put into breaking some changes down to smaller updates, with help of some intermediate "version branches". I have ended up sacrificing some badly needed maintenance on some other open-source projects and have also delayed responding to some people interested in helping me find some part-time work as well.

But I would like to give thanks to you @adalinesimonian for the work on your part, which has enabled this update in the first place, which I think will help many people in the near future.

[adalinesimonian]

@adalinesimonian I hope you are safe after the heat and the long weekend!

I am; thank you for your concern. Luckily, in my effort to distribute water and supplies, I only encountered minor heat exhaustion symptoms on several days, after which I immediately retreated home to recover. The fireworks I got to see this weekend made it all worth it.

I have incorporated most of the proposed changes in PR #630 and gave you some credit in README.md.

You undoubtedly did a lot of work! I appreciate the credit; it was certainly not necessary but thank you, nonetheless!

I did solve some CI issues a different way, unfortunately might have missed some of your changes in the process. I have raised issue #636 to start tracking some followup items needed. Please DO feel free to raise another PR if you think I missed anything important.

These updates have taken me almost a whole month to incorporate due to the work that I put into breaking some changes down to smaller updates, with help of some intermediate "version branches". I have ended up sacrificing some badly needed maintenance on some other open-source projects and have also delayed responding to some people interested in helping me find some part-time work as well.

I acknowledge that you've made more granular commits, which may, in certain circumstances, make it easier to identify specific sets of changes by making it such that the history refers to smaller groups of changes. However, after looking more closely at this effort, I don't believe this effort was worth the massive delay and other issues that it added to integrating changes from upstream. I find this especially true given that this will be far from the last time that there are significant changes upstream that we need to integrate down here.

We should have worked together in a unified set of changes throughout this effort so that our efforts were not doubled or split and kept shared knowledge together in one or a few places. Instead, that work became fragmented and introduced many points where there was a chance to miss things. This fragmentation also adds to the workload and delay (addressed in the following points).

• Multiplied points of failure — to be clear, what I mean as a point of failure in this context is a chance to integrate changes with mistakes or miss changes that are important. Each time you copied work into separate branches over and over again, it introduced the possibility of missing changes or implementing changes in ways that missed the nuance of or reasons for changes that were re-implemented. This possibility, ultimately, was not just a possibility, but a reality which you admitted to when you identified that there were missing changes. It also means we need to spend more time making sure changes are integrated without introducing issues and finding any missing changes. Finding absent changes was, as an example, a work item that we could have entirely avoided.
• Significant scope creep — this set of changes was meant to bring prettierX up to date with Prettier. Though additions such as option inheritance were (rightfully) removed due to being out-of-scope, other sets of changes, such as corrections to behaviour not introduced as a result of the merge, should have been dealt with after merging changes and not in this PR. Identifying ways to do things better here in prettierX is an excellent thing to do and worth the time; we handled that correctly at times by creating new issues. However, I don't believe we needed to increase the scope any more past integrating updates and having behaviour maintain with whatever the union of changes from Prettier and prettierX was, priority to the former.
• Increased workload — this approach of taking a more extensive set of changes and then re-doing them in separate branches and commits effectively doubles the amount of work required to integrate changes. Though we also worked together to smooth out changes, you also worked alone to copy all of that work all over again into multiple different branches. And on top of that, on several occasions, this led to me also having to re-do work to integrate it into branches you created. As you've said, you sacrificed the time needed to introduced badly-needed changes in other OSS projects and delayed getting back to people looking to pay you for part-time work, all just for smaller commits. I do not see this as a trade-off that makes sense.
• Significant delay — due to the increased workload, the delay with a routine update ballooned to a very long time, given how quickly a code formatter experiences and needs updates. I introduced the original PR prettierx: Merge Prettier 2.3.0 updates - draft 1 #549 43 days ago relative to when you finally merged changes into dev, which at the time of this message is yesterday. I introduced prettierx: Merge Prettier 2.3.1 updates - draft 2 #569 28 days and this PR, Merge additional changes from adalinesimonian/merge-prettier-2.3.1 #603, 19 days before the final merge. In the time since the original PR, Prettier released two patch changes. This delay compared to Prettier's pace of process didn't just add work but shows just how behind we can get if we continue to handle upstream changes in ways with such inefficiency. Unless we are more efficient, I don't have faith in this project keeping up with Prettier long-term without significant overhead or even, potentially, burnout.
• Less trackable and messy history on GitHub — commits aren't the only place where we keep information on changes. Those changes and the discussions that inform decisions take place in issues, PRs, and discussions (though we do not utilize discussions in this project). While commits may be more granular now, fragmenting changes into multiple branches, PRs, and scope creep has sprawled out the history of this set of changes across the repository. This well undoes any positive benefit of smaller commits. Now, it is more complicated and time-consuming for someone to dig through and locate all the different conversations we and others have had throughout this effort to understand the decision-making process better, the intent behind changes, and understand the scope of those changes. Having clear and organized places to find discussion, I would argue, is far more critical and practical than arbitrarily small commits. Prettier, upstream, doesn't chase small commits. However, because their work is all kept orderly, I was able to dig into history to find reasons for changes and discussion when working on this same set of updates for prettierX. If their commits were smaller, it wouldn't have added any benefit to my search.

This effort to make commits smaller felt like a task that had effort put into it without considering all the other ways in which it was detrimental to the overall effort of updating prettierX, nor the long-term consequences of handling more extensive sets of updates this way. I want to continue to contribute here to prettierX. Still, unless we address this issue of efficiency and complexity, I am not sure I will have the time to devote here and may instead switch to Prettier, where I will have more faith in the continued support of the project.

But I would like to give thanks to you @adalinesimonian for the work on your part, which has enabled this update in the first place, which I think will help many people in the near future.

I truly appreciate it! You're too kind. ☺ It was a lot of work, but together we were able to get it done. At the beginning of this effort, what motivated me to contribute these changes was that prettierX was unusable with Typescript due to lagging behind Prettier. If we can keep this project updated efficiently, it will undoubtedly help adoption. Not everyone has the time like I did to jump in and contribute significant changes, and will instead switch to the upstream project, a consideration that I think makes the argument I make earlier even more important.

[brodycj]

Thanks @adalinesimonian, happy to hear you had a good weekend!

And thanks for the candid feedback. Yes as I said before the work did go through too many circles, especially with the badly-managed scope creep which I should have kept out of this effort in the first place.

Here is what motivated me to in the smaller, more granular commits:

• I generally rely on the gitx tool on my mac (rowan-gitx from Homebrew). This tool seems to be unrivaled in terms of showing the history of all branches in a repository, which is extremely helpful for dealing with the git forking as in this project. The one thing with gitx is if a diff goes beyond a certain size, it collapses the diff view down to a "click to show diff" thing if a commit is too big, which then takes a moment every time I want to see the changes. This can be pretty disruptive when I am trying to understand and manage things going on in different branches and even different upstream repositories at the same time. I think this may be partly due to the way that gitx watches the git repository on the file system and dynamically updates its GUI upon git updates.
• I have been thinking about what will happen when I get a chance to rebase all of the prettierX updates on a newer version of the upstream Prettier codebase. My theory (and only a theory) is that the more granular commits should give me an easier and cleaner rebase effort.

I will look for a better way to manage this work over time.