dprint codebase

[jakebailey]

The first two commits run an eslint rule for trailing commas; this is just to eliminate it from the dprint diff as making our trailing commas consistent takes up a good portion of the diff. You can view just the "Run dprint" commit to see what dprint changed past that.

There are still some TODOs:

• The top of the stack is a change so that all of our files are linted; I have already sent this as another PR and will rebase it away.
• We have to decide when we run this
  • My initial preference was that this is enforced at CI time, like our linting.
  • However I know someone else mentioned that they had worked on a repo where a post-merge workflow auto-fixed any code changes, which sounds good too; dprint should be fast enough that if run on push, it's unlikely that anyone would be able to pull unformatted code onto their forks/branches, so format-on-save would still be viable for those who want it.
• There are a few minor cosmetic bugs, which have been reported on: https://github.com/dprint/dprint-plugin-typescript/issues/created_by/jakebailey
  • Reasonably, all that is left is that some comments containing visual spacing are changed, but I think that those ones should actually be JSDoc.
• The line length is set arbitrarily high; IMO we should take this opportunity to go down to something like 120. We have many files with ridiculous sizes. See also dprint codebase + lineWidth=120 and operatorPosition=nextLine #18.
• I have operatorPosition set to maintain; I would prefer nextLine (I find this much more readable), but right now we have a mix of both, but mostly sameLine. See also dprint codebase + lineWidth=120 and operatorPosition=nextLine #18.
• ESLint-related formatting rules need to be removed, as they no longer apply.
  • Doing so reduced lint time by about 6 seconds!
• Our settings.json template should list dprint as the formatter, and suggest the extension.
• Need to decide whether or not to format src/lib.
  • IMO we definitely should, especially as some lints are dropped. We already don't lint "generated" files.
  • Probably need to also format the output of the lib DOM generator.
• Need to vet any maintain uses, to ensure that it isn't possible to write "invalid" code and have it not be caught without our eslint rules. e.g. if statements without braces that are too big.
• Should we also format markdown? Seems like a good idea.
  • But, the style we appear to use in our docs and blog drafts appears to be the opposite of dprint, prettier, etc.
• Once this is committed to the repo, we should mark its commit ID in https://github.com/microsoft/vscode/blob/main/.git-blame-ignore to hide it from git blames.
• Need to improve dprint further to allow single line import { blah } from "..." instead of forcing multi-line.

[sandersn]

Looks like a good start.

[sandersn]

does this undo the trailing-comma eslint rule you enabled elsewhere?

[jakebailey]

No, since this is a JSON file, which aren't linted. If you open this file now in our repo, VS Code actually already complains, we just have nothing that can fix it.

[sandersn]

I'm not a huge fan of this additional line, although it's OK.

[sandersn]

I'd vote for a real line limit in the eventual PR; I don't like that this version produces overlong lines.

[jakebailey]

I don't like that this version produces overlong lines.

I think those cases can actually be "fixed" by making sure that they aren't hanging weirdly in the original code, which I can do earlier in the stack or after in a cleanup commit. But, yes, I do think that we should have a line limit.

[jakebailey]

microsoft#54820