chore: convert static site builder from Jekyll to Eleventy

[jgravois]

closes #287

Steps to test

Open the two sites side-by-side and compare

• https://11ty--compilerla.netlify.app/
• https://compiler.la/

TODO:

• chore: a few more miscellaneous 11ty fixes, consolidation and updates #326

Known discrepancies

1. 11ty adds trailing slashes to routes. ie: https://compiler.la/jobs becomes https://deploy-preview-302--compilerla.netlify.app/jobs/ but requests without the trailing slash should redirect seamlessly
2. each page now includes a <meta name="generator" content="Eleventy v3.1.6"> tag.
   (not sure why we don't currently have a jekyll flavored variant, i was under the impression that it was injected automatically.
3. <meta name="og:title"> and <meta property="og:description"> tags are now injected more consistently
4. bootstrap has been upgraded to 5.3.8
5. the production site includes a <script src="https://static.cloudflareinsights.com/beacon.min.js..."> tag. i assume this is injected by Cloudflare itself and will persist when the 11ty site is deployed, but will make a point of confirming.
6. in this branch <link type="application/atom+xml" href="/blog/feed.xml"> is an absolute url instead of a fully qualified domain name. i don't think that's problematic, but if anyone else disagrees, it'd be trivial to make it match.

[netlify]

✅ Deploy Preview for compilerla ready!

Name	Link
🔨 Latest commit	bd0f7cc
🔍 Latest deploy log	https://app.netlify.com/projects/compilerla/deploys/6a31a2099ee5160008b559a4
😎 Deploy Preview	https://deploy-preview-302--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.

[jgravois]

merging #318 introduced a merge conflict here and #319 should really include the blog post we published in #301 anyway.

as i see it we have two options, either of which feel reasonable:

1. rebase the 11ty branch on top of main
   (and update the SHA listed in the .git-blame-ignore-revs file)
2. merge main into the 11ty branch
   (and tolerate the merge commit)

i know @angela-tran has expressed (understandable) squeamishness about managing history in long-running branches. if there's a tack that y'all prefer, i will make it so.

[angela-tran]

@jgravois - I was thinking about all this (the recent blog post merge into main and the 11ty branch) earlier today too so I'm glad you asked. ❤️

My thought on the immediate question is that Option 1 aligns the most with our convention to rebase rather than merge the base branch. So yep, option 1 was how I was thinking we should handle it.

My thought on my past comments about managing history on long-lived branches is that those were more about how, if we're working on a feature branch with many interdependent changes coming in from different PRs, I would prefer that all those PRs target the feature branch, rather than some of them targeting main. This scenario happened when we were working on the MobiMart Rider Benefits page; from looking at the Rider Benefits design, we found some site-wide adjustments that needed to happen, so there was ambiguity over whether those should target main or the feature branch -- that is, one person might think of the changes as tangential clean-up that should be deployed to the live site without waiting on the feature being completed, while another opinion might be that those changes came about because of the feature and therefore are a part of it and should be QA'd along with all of it. I take that latter position because it means we can avoid rebases that feel unnecessary and possibly disruptive if many developers are involved.

I'll link to those comments in case it's helpful context for anyone:

• Style: related-nav-link hover and focus states cal-itp/mobility-marketplace#894 (review)
• Style: allow more room for pull-quote attribution cal-itp/mobility-marketplace#905 (review)

In this case with compiler.la / the blog post, it was much more clear-cut that the blog post was totally independent of our 11ty refactor and needed to be deployed to the live site as soon as it was done. So in this case we have a rebase that cannot be avoided, and that's fine.

That's how I view it at least. I'm happy to discuss this more if anyone disagrees with what I'm suggesting 🙏

[jgravois]

thanks for the thorough write-up and including those links.

another opinion might be that those changes came about because of the feature and therefore ... should be QA'd along with all of it. I take that latter position

i'm all for avoiding rebases when possible. on that note, i'll wait to rebase this branch on top of main until after #319 is reviewed/merged if it's okay with y'all. 🤗

[angela-tran]

i'm all for avoiding rebases when possible. on that note, i'll wait to rebase this branch on top of main until after #319 is reviewed/merged if it's okay with y'all. 🤗

That sounds good to me. Hopefully the merge conflicts aren't too bad when you get to the rebase 🤞 😅 🤗

[Scotchester]

Rebases… can't live with 'em, can't live without 'em; am I right?

(I agree with the proposed course of action.)

[jgravois]

Hopefully the merge conflicts aren't too bad when you get to the rebase 🤞 😅 🤗

luckily they weren't bad 😉

Resolved in #326