Use prettier for code formatting about fluidframework

[christiango]

@tylerbutler , this is another good candidate for looking good when we go public.

[christiango]

Bumping this, we should really consider this before going OSS @curtisman. As someone who works in multiple repos, I don't really don't want to have to learn the particular nuances of each repo's style guide. Prettier is an industry standard

[tylerbutler]

I have a couple of general thoughts before I share my opinion. First, I categorize contributors into two groups - core and incidental. Core contributors are working in the repo regularly, while incidental contributors are bringing bug fixes, individual features, etc. (basically anything and everything) but they're not keeping up-to-date on the details of how the repo works. When we talk about this issue, we should articulate these two groups (at least) and how our decisions will affect them.

Second, one of the key goals in the repo structure is that each package could live independently in its own repo. Thus, I think it's reasonable for some packages to use prettier and others not - especially with example components. I recommend we use this issue to discuss whether prettier should be a top-level every-package-in-the-repo thing. Then based on the outcome we can decide if individual package discussions are worth having.

Finally, I suggest that we break this discussion down a bit more into the key benefits of prettier over alternatives. I don't agree that it is an industry standard. Or at least, there are alternatives with lots of usage too (e.g. editorconfig). We have ESLint rules to catch things like line endings and line lengths, and spaces/tabs, .editorconfig files to autoconfig indentation and spaces/tabs (we could very well have gaps here), etc. What are the key benefits to prettier that we don't already have?

[christiango]

Thanks for the thoughts! I definitely fall into the later category (incidental contributor) and currently there's quite a bit of a context switch I have to do when I want to change something in the repo. There are some expected friction points, like familiarity with the build commands and the package structure, that will get better as we add documentation. As a side note, I would caution against grouping developers into different categories so we can continue to build an inclusive community around Fluid. Ideally, what's good for new or occasional developers to the repo should also be good for those who work in it every day.

Within Microsoft and on some of the open source projects I've worked on, I really enjoy it I go to a project and I don't need to know the coding conventions of the project or manually be fixing lint errors to get a change in. A great experience here makes the difference between just logging an issue and actually being motivated to try and fix it in the repo.

Prettier isn't perfect, and I certainly don't love some of the default choices they've made. However, what I do enjoy is that we don't have many arguments over code style formatting as we did before using Prettier.

Another thing that's nice is that this is something that's pretty widely used by open source projects (React, Fluent-UI) and the big web apps at Microsoft (Outlook Web, Office Online, Teams, OneDrive/SharePoint).

While I think alignment on conventions and tooling is good for the Microsoft web community as a whole, the Fluid team should absolutely be empowered to do what's best for the project developers. All I ask is that we make sure that the experience is as good as a prettier enabled repo to make sure folks that work in multiple repos don't hit friction points when working in Fluid. To me this includes:

• Automatic enforcement of all style rules. We shouldn't be relying on tribal knowledge or nit comments in PRs.
• A way for developers to automatically have styling related discrepancies automatically resolved for them in the inner loop. Having this on by default has been successful in many of the repos I have worked in, but I'd settle for some well documented lightweight way to opt in to this.
• Coding conventions that don't differ too dramatically from what the other large Microsoft JS/TS projects use.

[tylerbutler]

Prettier isn't perfect, and I certainly don't love some of the default choices they've made. However, what I do enjoy is that we don't have many arguments over code style formatting as we did before using Prettier.

That's fair, and an outcome I welcome. There are far more important thing to argue about, after all! :)

NOTE: This is an opinion.

My personal beef with prettier is that it obsesses about fitting as much on a line as possible, so then you futz with the line number to get things "sort of good" but it still pales in comparison (IMO) to what VS Code formats out of the box if you give it some hints about indentation, line endings, etc. VS Code seems to have that near-perfect balance of opinionated vs. not. It will helpfully correct mistakes like missing spaces between function arguments and whatnot, but it (usually) won't rewrite my manually indented code that could fit on one line but that I know as a reasonably intelligent developer works better on multiple lines. So then I'm... commenting code so it doesn't get reformatted?

Anyway, since my personal ideal is VS Code's Format Document, I investigated just using it directly and found typescript-formatter. It appears to be what VS Code itself uses. I ran it on the client mono-repo as a test; results plus a couple of manual tweaks are in this commit.

It seems a bit outdated, though, and it's not perfect either. This commit contains some questionable changes. My hunch is that some modern TypeScript syntax + JSX trips it up.

Anyway, I think for comparison, I'll do this same exercise using a prettier config, so we can compare the results. My default is to use Fluent's prettier config, but if you have a different suggestion let me know @christiango.

[christiango]

This is awesome Tyler! I'm definitely open to other approaches here and am more interested in the final state, where we have some conventions we don't completely hate and that can be enforced/maintained with tooling.

Yeah, prettier does have the nice feature that it is currently well maintained and supports React syntax. In terms of prettier config, Fluent's is a good start. On the Fluid Experiences repo, we just have this config:

{
  "printWidth": 120,
  "singleQuote": true,
  "trailingComma": "none",
  "endOfLine": "auto"
}

[tylerbutler]

more interested in the final state, where we have some conventions we don't completely hate and that can be enforced/maintained with tooling.

We're on the same page. :) Thanks for pushing us on this!

[tylerbutler]

I experimented with Prettier as well, with three different line-lengths: 80, 100, and 120. I ran it against all the client packages, same as typescript-formatter. Results for comparison are linked below.

• typescript-formatter: tylerbutler@a69171c
• prettier 80: tylerbutler@d3744d3
• prettier 100: tylerbutler@7a43833
• prettier 120: tylerbutler@f5e7b18

Pick a file and compare the changes between the four versions. Here's some direct links to some files:

---

components/experimental/flow-util-lib/src/resizeobserver/index.ts

• typescript-formatter: tylerbutler@a69171c#diff-ac335e85895723c06eebb615d6d699b7
• prettier 80: tylerbutler@d3744d3#diff-ac335e85895723c06eebb615d6d699b7
• prettier 100: tylerbutler@7a43833#diff-ac335e85895723c06eebb615d6d699b7
• prettier 120: tylerbutler@f5e7b18#diff-ac335e85895723c06eebb615d6d699b7

---

components/experimental/vltava/src/components/tabs/dataModel.ts

• typescript-formatter: tylerbutler@a69171c#diff-4d8c53a2bbf163cecbf989b6a8c894be
• prettier 80: tylerbutler@d3744d3#diff-4d8c53a2bbf163cecbf989b6a8c894be
• prettier 100: tylerbutler@7a43833#diff-4d8c53a2bbf163cecbf989b6a8c894be
• prettier 120: tylerbutler@f5e7b18#diff-4d8c53a2bbf163cecbf989b6a8c894be

[christiango]

Thanks for sharing! I would be ok with any of these to be honest, maybe with prettier 80 being my least favorite. What are you leaning towards?