Add prettier support

[lukekarrys]

This PR contains 4 commits:

1. 9ca6167 adding prettier support to @npmcli/template-oss
2. d020c1d enabling prettier on this repo by setting templateOSS.prettier: true
3. 685dd64 running prettier to format this repo
4. 770a10c add a .git-blame-ignore-revs file referencing the commit from item 3 Dropped from this PR since SHAs won't match after rebase

Once this lands, enabling prettier on another repo will involve updating to the new version of @npmcli/template-oss, and then running steps 2-4 which should be handled by a new script in https://github.com/npm/stafftools (or another tool).

---

The most important part of item 1 is the implementation of the lint and lintfix run-scripts. They now look like this:

{ "lint": "npm run eslint && npm run prettier -- --check", "lintfix": "npm run eslint -- --fix && npm run prettier -- --write" }

The goal here was to have the same lint and lintfix scripts we currently have also be responsible for running prettier. The tradeoff is that if linting fails, then formatting via prettier doesn't run. I think this is ok since it allows for a single script to handle both eslint and prettier.

We also explored using a combination of postlint and postlintfix for this, but then prettier --check (via lint->postlint) would get run before prettier --write which would defeat the purpose of prettier --write.

---

Other notable items are:

• Uses @github/prettier-config except for changing bracketSpacing: true to match how we previously had eslint setup. This also sets arrowParens: "avoid" which seems like something we've never standardized on previously, so we opted to leave it as configured in the @github config.
• Uses eslint-config-prettier to overwrite all the eslint formatting rules we use. Alternatively we could remove them all from @npmcli/eslint-config on a semver major of that. I think it's easier to get more things on prettier before a decision on that is made.

[wraithgar]

This may warrant .git-blame-ignore-revs

[jumoel]

Nice 💅

Ensure that this isn't squash-merged, or the rev in .git-blame-ignore-revs will be wrong.

[wraithgar]

Will rebase-merge preserve the commit sha?

[lukekarrys]

I checked on npm/cli for a recent multiple commit PR that was rebased and even a rebase merge will also change the sha.

For this PR I will probably land it, temporarily change branch protections, and then force push a new commit to main referencing the correct commit.

For other repos I think the prettier application and git-blame-ignore-revs creation will need to be multiple PRs.

[wraithgar]

For other repos I think the prettier application and git-blame-ignore-revs creation will need to be multiple PRs.

Let's practice it here then. Don't bother disabling the branch protections. Search for past "lint everything" commits to this repo, including the one from this PR, and make a new PR adding them. That way we can live the process we'll be using going forward.

[lukekarrys]

@wraithgar Good call. Just dropped the .git-blame-ignore-revs commit from the PR and will make a followup adding the SHA for the prettier formatting commit as well as any other lint commits I can find.

[wraithgar]

It seems appropriate that @jumoel or @reggi approve this.

[hashtagchris]

Once we've adopted prettier in most repos, we may to separate linting and styling.

We could add dedicated style and stylefix scripts, and have posttest run {{ localNpmPath }} run lint && {{ localNpmPath }} run style

[hashtagchris]

@lukekarrys @jumoel Is there a reason we're making prettier usage configurable? Are there repos we know we don't want to use prettier in? Do we want a gradual or coordinated rollout of prettier?

[lukekarrys]

As I recall, it took some semi-manual effort to roll out prettier to a new repo due to the .git-blame-ignore-revs file and getting the right SHA after merging the PR. So it was made configurable with the goal of turning it on everywhere and then changing the default after that.