Selectively import USWDS packages #422
Conversation
|
Terraform plan for tts-10x-atj-dev Plan: 0 to add, 2 to change, 0 to destroy.Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
!~ update in-place
Terraform will perform the following actions:
# cloudfoundry_app.tts-10x-atj-dev-server-doj_tts-10x-atj-dev-server-doj-app_380DB029 will be updated in-place
!~ resource "cloudfoundry_app" "tts-10x-atj-dev-server-doj_tts-10x-atj-dev-server-doj-app_380DB029" {
!~ docker_image = "ghcr.io/gsa-tts/forms/server-doj:b355f84dd5bd7cf8779360db7b238b6b5185856c" -> "ghcr.io/gsa-tts/forms/server-doj:a1ff3c217f2c575efe7d27b7a64d0a96c5200ecf"
id = "8a9fc8b6-af5e-45a2-abb6-2c24ecbcdfaa"
name = "tts-10x-atj-dev-server-doj-app"
# (17 unchanged attributes hidden)
# (3 unchanged blocks hidden)
}
# cloudfoundry_app.tts-10x-atj-dev-server-kansas_tts-10x-atj-dev-server-kansas-app_337A9CF1 will be updated in-place
!~ resource "cloudfoundry_app" "tts-10x-atj-dev-server-kansas_tts-10x-atj-dev-server-kansas-app_337A9CF1" {
!~ docker_image = "ghcr.io/gsa-tts/forms/server-kansas:b355f84dd5bd7cf8779360db7b238b6b5185856c" -> "ghcr.io/gsa-tts/forms/server-kansas:a1ff3c217f2c575efe7d27b7a64d0a96c5200ecf"
id = "e885e531-11b7-4906-9cc3-0ddf483868f5"
name = "tts-10x-atj-dev-server-kansas-app"
# (17 unchanged attributes hidden)
# (3 unchanged blocks hidden)
}
Plan: 0 to add, 2 to change, 0 to destroy.📝 Plan generated in Post Terraform plan to PR comment #520 |
There was a problem hiding this comment.
Tracking what we use across multiple packages might be kind of hard, over the longer term. On the other hand, some of this modularization was maybe a bit premature, given that we don't have use cases for embedding in other sites, yet.
So this seems like a good improvement, but we should perhaps think about how we can encapsulate the styles for better reuse. Perhaps if we end up using the USWDS web component patterns, that will address encapsulation concerns?
|
@danielnaab - another way to do this would be to use purgecss in the build step to clean up any unused styles and run it against the built Astro site. That way, it would use a tool to automate the removal of unused styles, and we wouldn't have to track it manually. Do you like that any better? It's easy enough to implement. The USWDS web component package is still in the very early days, and when I talked to the USWDS team they did mention that they were going to be supporting concurrent versions (web component and vanilla JS/CSS) for a while. Also, they are trying to stick to as much light DOM as they can with the web component build, so it wouldn't encapsulate the styles. |
Use packages instead of big uswds import. This helps cut down on the amount of unused CSS we're shipping.