Start to build project list page.

[Gaelan]

Problem

It'd be nice if there were a single list of open-source projects at CMS, with clear descriptions and minimal noise. Both nice as a marketing tool, and provides a useful foundation for other Open Source Program initiatives.

Solution

Pull a list of public repos (from @CMSgov @DSACMS @CMS-Enterprise @Enterprise-CMCS - let me know if you know of more orgs!) and use it to build some static pages.

However, a plain list of repos isn't particularly useful - many of our projects are spread across multiple repos (notably AB2D, which has about 15, and the Acceptable Risk Safeguards cybersecurity auditing stuff, which has dozens), and many of our repos have no description or descriptions that aren't particularly helpful. Thus, I built a manual override mechanism for hiding deprecated/useless repos, improving descriptions, and merging multi-repo projects into one "primary" repo. Ideally in the long term this'd be managed by the teams that publish the repos (it should be pretty easy with GitHub's GraphQL API to read metadata from a cms-code.json file in the root of each repo), but that's going to take a ton of coordination, and I suspect there will always be an issue or two we need to correct on our end, so it's worth supporting manual overrides.

I've done manual overrides for a bunch of the more popular repos to clean things up a bit, but that's not by any means complete.

Also still to do: refining the styling a bit - in particular I'm pretty sure I'm doing the two-column layout wrong, and it really should collapse down to one column on narrow screens. Some other content for the site is in order as well, but that can probably be a separate PR.

Result

Test Plan

Manually viewed the generated pages.

[Gaelan]

right, re using USWDS: the Cloud.gov folks have a template at https://github.com/cloud-gov/pages-uswds-11ty that looks more or less perfect (and I did a version of it with 11ty 2.0 in https://github.com/cloud-gov/pages-uswds-11ty/pull/33). @patsier-cms is it worth trying to set things up with the existing structure you've got going here, or just copy that template over wholesale? Looks like mildly different approaches to build tools - they use esbuild, you use rollup, and they've got some sort of semi-convoluted thing for getting esbuild to output a JSON file full of cachebusted filenames that 11ty then reads.

[patsier-cms]

@Gaelan up to you! The benefit of 11ty is that it's really flexible, so we aren't tied to either one and can pull whatever we need. I built mine around having as little JS as possible and inlining, but that esbuild cache-busting setup could make sense too. Could be worth trying either out or picking and choosing pieces that work best from each?

[Gaelan]

Here's the new version:

The big changes are:

• Switch from CMSDS to USWDS.
• Bunch of toolchain changes. This is what I settled on after like 3 different iterations (sigh, modern web dev). The big changes are:
  • Use the new eleventy-plugin-vite so everything's running under one process and we're not juggling separate build tools. Also lets us drop/simplify much of the rollup/postcss config. Vite supports Sass, which could be useful if we want to make use of things USWDS exports only as Sass stuff, but that's a bridge to cross when we get to it.
  • Use liquid instead of nunjucks, because I'm utterly spoiled by Prettier and there's a good Prettier plugin for Liquid.
  • Not strongly attached to either of these decisions, please tell me if they're a bad idea for some reason.
• Redesign the projects page using USWDS components.
• Add a "category" system to group repositories roughly into what type of artifact they are - mixed feeling on how useful this is. Eventually we'd want a way to maintain this category metadata within each repo.