chore: configure prettier pre-commit step and autoformat entire repo

[jgravois]

closes #296

• first commit configures prettier in a way that is compatible with pre-commit and converts a few liquid templates to be more explicit.
• second commit lets prettier cook
• third commit turns on pre-commit to prove all is well.
• last commit adds a .git-blame-ignore-revs file

personally i'm fine with prettier and the shopify plugin's defaults, but @angela-tran, feel free to play around and test the effect of making changes to the options for quotes (or anything else) if you'd like.

[netlify]

✅ Deploy Preview for compilerla ready!

Name	Link
🔨 Latest commit	f9f27cb
🔍 Latest deploy log	https://app.netlify.com/projects/compilerla/deploys/69f3b8a9a17f7c00080052de
😎 Deploy Preview	https://deploy-preview-300--compilerla.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[Scotchester]

A few comments to get us started.

[Scotchester]

i'd like to wait until we're reasonably certain we don't want to change any other prettier/shopify defaults before i rewrite history

I'll preface this by saying, if this is the same config you just implemented on calitp.org, I am totally fine to roll with it, but if we're opening the discussion… skimming through the formatting commit's diff, there are a few things that stand out to me:

• This kind of breaking of tags across different lines remains intensely annoying, but IIRC we couldn't find a reasonable way to avoid it.

  <span class="secondary-sans-serif-xs d-inline-block pb-4 mb-3"
    >An inside look at Compiler’s internal projects, interests and our client projects.</span
  >

• Indendation inside {% comment %} blocks. I guess NBD if the comment toggle shortcut in VS Code handles the indentation/deindentation automatically.
• I prefer having the first attribute of an HTML tag on the same line as the tag name and the subsequent attributes lined up with it on the lines below.
• I don't like that it's adding a / before the closing > of self-closing tags.
• I like the (old school?) convention of not indenting an HTML doc's head and body tags, but this is the least offensive thing on this list to me.

[jgravois]

if we're opening the discussion...

if anything in that tick list can be mitigated/improved by altering prettier or shopify's defaults, I'm not opposed.

with regard to the tag wrapping, I too recollect that we tried and couldn't find a suitable alternative, but it's not outside the realm of possibility that there's something we missed.

I have to admit that my personal enthusiasm for optimization is low. I'm happy to just accept prettier's defaults, but if anyone else wants to play around with this branch before the PR is merged or create another branch of their own later, all the pieces are present to automate reformatting the entire repo and ensure that the diff is ignored afterward.

[Scotchester]

Seems like a decent way to spend the last couple hours of the ride into Chicago :)

As I brought up the docs to dig into what options were available, I noticed this in the VS Code extension's README:

Note: VS Code does not support combined language syntax for editor.defaultFormatter. You must set the formatter for each language separately:

// ❌ This will NOT work
{
  "[javascript][typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  }
}

// ✅ Use separate blocks instead
{
  "[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  }
}

I'll see if I can test this out.

[Scotchester]

As I brought up the docs to dig into what options were available, I noticed this in the VS Code extension's README:

Note: VS Code does not support combined language syntax for editor.defaultFormatter. You must set the formatter for each language separately:
// ❌ This will NOT work
{
"[javascript][typescript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
}
}

// ✅ Use separate blocks instead
{
"[javascript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[typescript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
}
}

I'll see if I can test this out.

I haven't completely confirmed this yet, but I DID run across two other things I want to mention quickly:

• [jsonc] must be explicitly included in order to have the default formatter apply to JSON with Comments files, e.g., devcontainer.json and .vscode/settings.json.
• This complication from the VS Code settings docs:

  If you are using multiple language-specific settings, be aware that language-specific settings are merged and precedence is set based on the full language string (for example "[typescript][javascript]") and not the individual language IDs (typescript and javascript). This means that for example, a "[typescript][javascript]" workspace setting will not override a "[javascript]" user setting.

Maybe this is referring to the same root issue as the Prettier extension README, but it seems like whatever the case, we'll want to list each language separately.

[jgravois]

it seems like whatever the case, we'll want to list each language separately.

in the wild so far we've only seen a collision for json (you) and html (@angela-tran). personally i'm fine with limiting our overrides to what we've actually seen, but if you prefer to be exhaustive, i don't have a problem with that either.

[indexing]

@jgravois I've reviewed this PR, as well as the issue and parent issue, but I don't have anything to add to this convo. Let me know if there is anything in particular on which to focus.

[jgravois]

indexing reviewed on behalf of https://github.com/orgs/compilerla/teams/compiler-comms 35 minutes ago

all good @indexing!

@compilerla/compiler-comms is assigned by default in this repo anytime a change is made in the _posts directory with the assumption being that we're usually either publishing a new blog or making a copy change.

compiler.la/.github/CODEOWNERS

Line 3 in dafad11

_posts/ @compilerla/compiler-comms

if you ever see a PR like this that isn't a clear attempt to update the content on the https://compiler.la website, i'd say its safe to ignore. you're also always welcome to ask for clarification before you spend time on a fullblown code review.

[Scotchester]

I just did some more testing with vscode-settings-inspector to confirm that listing them individually works and listing them together does not.

in the wild so far we've only seen a collision for json (you) and html (@angela-tran). personally i'm fine with limiting our overrides to what we've actually seen, but if you prefer to be exhaustive, i don't have a problem with that either.

It's just such a hidden footgun, and hard to realize exactly what's happening when it goes off, I would prefer to be exhaustive, yes. I could push that change to this branch, if you're cool with that.

[jgravois]

I could push that change to this branch, if you're cool with that.

of course. you have my blessing! 📿

[angela-tran]

I just did some more testing with vscode-settings-inspector to confirm that listing them individually works and listing them together does not.

I did some testing and can confirm too that we need to list them individually. Thanks for catching @Scotchester!

[angela-tran]

This looks good to me 👍

I'm good with sticking with prettier's defaults. We can always revisit it, and I think getting through the 11ty conversion work is the higher priority.

[Scotchester]

Having satiated my curiosity about the process of updating Prettier in the future, I concur with Angela, let's merge this and move forward.