Consider updating automated code formatting tools' rules

[howard-e]

Currently, the auto-formatting tools uses prettier's default printWidth rule which defaults to 80. As the project grows and there are more deeply nested branches in the code, contributors have raised concerns or questions when it comes to readability (and perhaps ease of maintainability in some cases):

• Update hashTests function to support the migration of test results across test plan versions using the v2 test format #880 (comment)
• Update Test Runner for V2 Test Format #843 (comment)
• Warning modal for creating duplicate test plan runs #901 (comment)

Generally, this discussion is a matter of "personal taste", but it seems the currently active contributors on this project align on increasing this number for practical readability reasons. Is there a reason to not to do this? What should it be increased to?

[howard-e]

Possibly related question - should tabWidth be considered in this discussion?

[stalgiag]

Thanks for starting this discussion @howard-e ! I have wanted this for a while. We are deeply nested in many places and the default printWidth is frequently chopping up our code. I do think this is partially an invitation to nest our code less (smaller components, dedicated functions, not nesting conditionals where possible) but there is a lot of code that we won't be refactoring anytime soon that would have increased readability from a higher printWidth

[alflennik]

Great idea!

Could I suggest we use tabWidth: 2 for the same reason? Which is also more idiomatic for JavaScript.

Also to improve git diffs I was wondering if we could use trailingComma: 'all'.

[jugglinmike]

Thanks for starting this discussion, @howard-e.

My comment is an outlier among the three that you've referenced in that I was looking for guidance on the reduction of line length. Prettier's "printWidth" feature won't help us in that case as it tolerates string literals of any size. For what it's worth, I'm in favor of a strongly-enforced conventional maximum line length for the reasons that @stalgiag cited above. If the only hesitation to adopting such a policy is the existence of non-conforming code, I recommend making exceptions with in-line comments as necessary, both as a stop-gap for future contributions and as an explicit marker of intent for future refactoring.

[stalgiag]

I think I agree with what @jugglinmike is proposing here as I do think there is useful accountability in the printWidth default. I would also say that this accountability is only useful if there is social reinforcement.

Going off @alflennik's, I would be in support of maintaining the default Prettier printWidth while changing the tabSize to '2'. This has become the most widely used tab size in modern JS projects and it would immediately improve readability across the entire project. This would then give us a fresh starting point from which to be more discerning about nesting depth while writing and reviewing code going forward. When reviewing, I currently worry that I will come off as nitpicky when I think to point out issues with readability when there are broad swaths of the project that have these issues. It might feel easier to establish a new standard that we all hold ourselves/each other to if we can see the advantages that come with improved readability.

[howard-e]

A follow up on this is to create a PR which updates the project's default tabWidth to 2 to see how that addresses offending instances of odd formatting observed in the code.

Additional consideration for updating the printWidth to 100 may happen during that PR's review.