Ruby 3.1 upgrade

[drewbo]

Changes proposed in this pull request:

• Rewritten asset pipeline to remove jekyll-assets (re: Consider migrating away from jekyll-assets pages-uswds-jekyll#186)
• Switch to Ruby 3.1.3
• Use parcel as the primary asset handler

Remaining items

• A few remaining instances of asset_url/asset_path need to be removed. As part of this, the USWDS overrides should be removed and the asset paths "hardened" (right now I swapped many of the initial paths to '../' so they find their way out of the css folder)
• Broken docs navigation
• Inspect all pages for broken links/images/css
• The local dev server is deeply broken and I highly recommend not trying it (it runs too many processes in parallel)
• image minification
• Assess whether asset fingerprinting/integrity checks need to be added back in
• Assess whether css can be further reduced in size/compressed
• admin/netlify cms is broken

😎PREVIEW URL

Security Considerations

New dependencies, upgraded Ruby

[drewbo]

Assuming I can check those last few boxes above and fix the build in the next day or so, I think the next move is to evaluate whether (1) this seems like a plausible future for cg-site and (2) seems like a plausible future for sites based on https://github.com/cloud-gov/pages-uswds-jekyll. My thoughts on how this works so far:

• it's nice to have a single _assets folder and each of the parcel/npm scripts are fairly straightforward/readable
  • copies over documents and static js
  • uses built-in sass/postcss compilation on files in css + USWDS as specified in .sassrc
  • uses built-in image minification on images
• it's a bit brittle but okay to use jekyll alongside another asset handler:
  • not using the assets folder breaks the ability to use {% link ... %} but having assets plus another _assets folder for files prior to preprocessing is pretty confusing (parallel pipelines)
  • the dev server situation is difficult because jekyll wants to overwrite assets in the built folder but we're putting other things there. In the build, we can run things serially, but using watchers creates a waterfall of dependencies/race conditions.
• this isn't the core use case for parcel (it desperately tries to interact with JS files) but it seems okay at least for the build step
• I tried my best to minimize dependencies but this does add a few as well as a number of npm scripts.

[drewbo]

This is probably ready to merge. Remaining weak spots of things to review:

• Deleting the current package-lock.json and reinstalling will create a different lockfile, something to do with "@parcel/transformer-sass". I'm worried that this creates some instability for new installs
• The local dev server works but seems a little breakable and still starts too many parallel watch processes
• Final asset/image review
• We need to either skip SRI on DAP or get them to add CORS headers (otherwise it doesn't load)

[hursey013]

Few small suggestions, all just style/syntax, otherwise looks good!

[hursey013]

Not needed when using .ruby-version

[hursey013]

Could potentially replace with node-version-file: '.nvmrc' to try to limit the number of places where we need to change the node version.

[hursey013]

This always made me nervous, glad to see it go.

[hursey013]

Idea: alternative syntax that I gravitated towards as being more readable, but totally my own personal preference:
!["App Overview dashboard"]({{ "/assets/images/content/app-overview.png" | relative_url }})

[hursey013]

Suggested change

	"prod:parcel": "run-p build:css build:static:js build:static:docs build:images",
	"prod:parcel": "run-p build:*",

[drewbo]

Documenting for postering but I've removed the subresource integrity build process:

• For our one third-party script, Digital Analytics Program, we received the following guidance:

It's not a good choice for calling third party scripts from a location where that org changes the code. So, from our dap.digitalgov.gov host, the hash would break whenever we pushed an updated code version. You could enable SRI if you self-host, but then you don't get our automatic feature/security/bug fixes when we push new versions. So enabling SRI is foregoing one measure of security (our maintenance of the code) for another (assuring the code has not been tampered with)

• For local files, there isn't a clear threat model because if an attacker has access to modify our hosted JS, they either have access to the build process or the CDN, either of which mean they could circumvent the SRI check to begin with. In the abstract, I would leave the check in to as an additional layer of security but the library we're using to replace the previous jekyll assets sub-dependency doesn't easily allow for partial SRI application (adding the check to certain files and not others).

[markdboyd]

@drewbo I did some initial checking over the preview build and here's what I found:

• Drop-downs in the top nav aren't working and there seem to be related JS errors in the browser console
• Clicking links in the side nav not working on on a page like https://cg-88d42ca6-59d7-47e0-9500-4dd9251360b9.sites.pages.cloud.gov/preview/cloud-gov/cg-site/chore-ruby-3.1-upgrade/contact/

Also, when testing the ability to build the site locally, I found:

• I got local changes to Gemfile.lock
• Styles aren't loading on the local site. Relevant console error: Refused to apply style from 'http://localhost:3000/assets/css/styles.css' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.

[markdboyd]

Everything looked good when testing a local build and in the Pages build. Great work!