LNHU-301: Enqueue each style sheet of the v2 system directly to introduce theme versioning

[djanelle-mit]

Developer

We recently started using a v2 style system that uses raw CSS instead of SASS. Raw CSS import functions don't compile down to a single sheet like sass does, they're references to a specific file. Because of this, they don't get versioned like other enqueued files in the Wordpress theme, even when the main file is versioned.

This work enqueues those style sheets and links relevant dependencies to force versioning.

Stylesheets

• Any theme or plugin whose stylesheets have changed has had its version
  string incremented.

Secrets

• All new secrets have been added to Pantheon tiers
• Relevant secrets have been updated in Github Actions
• All new secrets documented in README

Documentation

• Project documentation has been updated
• No documentation changes are needed

Accessibility

• ANDI or Wave has been run in accordance to
  our guide and
  all issues introduced by these changes have been resolved or opened as new
  issues (link to those issues in the Pull Request details above)

Stakeholder approval

• Stakeholder approval has been confirmed
• Stakeholder approval is not needed

Dependencies

YES | NO dependencies are updated

Code Reviewer

• The commit message is clear and follows our guidelines
  (not just this pull request message)
• The changes have been verified
• The documentation has been updated or is unnecessary
• New dependencies are appropriate or there were no changes

[matt-bernhardt]

This looks pretty good overall - I like that we're restoring the original filenames here during the transition.

My requested change is to just delete the v2.css stylesheet, on the reading that we don't need it anymore - and I'd like to prevent future-us from thinking that it was omitted accidentally.

I have an unrelated ask-to-confirm comment about the change to the buttons component styles, but no answer there will change my approval.

I'm curious how we'll go about spreading this style system to other pages (if we'll have, say, a v2-hours sheet for that page, and a v2-locations sheet for that template, which also declare all the dozen components as dependencies, or if we'll need an empty v2 container that gets called across all v2 pages), but that's a problem for later.

[matt-bernhardt]

If I'm correct, this entire file can be removed? The changes to functions.php add all these files to the register/enqueue system on their own, and this aggregation layer is being removed (correctly, to prevent duplication).

[djanelle-mit]

Deleted! When we centralize we can replace all of the individual registrations with a single v2 file via CDN or other central delivery method.

[matt-bernhardt]

Am I right in thinking that this is bringing the border-radius variable into line with the terminology being used in the corners component stylesheet?

I don't mind this change being in the changeset either way, but want to understand whether I should be incorporating this into the intent of all the other changes.

[djanelle-mit]

Yep, this was a typo. I used CoPilot to set up all the dependencies, and it caught this miss in the process. It wasn't noticeable since it is the default setting, but nice to streamline as part of this.

[matt-bernhardt]

Great! Thanks. I'm looking forward to seeing this all in action.