Add lit and initial web components

[anselmbradford]

Additions

• Add a new "elements" page with initial web components: cfpb-button and cfpb-file-upload.
• Add lit dependency for web components.

Testing

1. Check components > elements page for example web components. https://deploy-preview-2264--cfpb-design-system.netlify.app/design-system/components/elements

Screenshots

[netlify]

✅ Thanks for the improvements! Browse a preview of your changes using the link below.

Name	Link
🔨 Latest commit	09f0434
🔍 Latest deploy log	https://app.netlify.com/projects/cfpb-design-system/deploys/684c44e275cd9a0008806914
😎 Deploy Preview	https://deploy-preview-2264--cfpb-design-system.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.

[anselmbradford]

Regular components /dist/ files are receiving uncompressed dupes of the web components code. Lemme know if you see why.

[wpears]

This looks directionally correct to me! I do wonder about trying to isolate scss from component code. That is, instead of having component scss with use statements that gets loaded as a text, what if we put the translation from scss-land into lit css template tags higher up, that is, in core, vars, etc. Then in component code we could simply import { vars } from './where/ever.js' and use them as normal in lit.

There's kinda a delicate dance, I'll admit, between maintaining scss for child consumers (mostly cf.gov) and making the lit components more idiomatic. Not sure what the best thing is here.

As to the practicalities of this PR, looks like there's some commented stuff in the file-upload index.js file we could trim.

[anselmbradford]

This looks directionally correct to me! I do wonder about trying to isolate scss from component code. That is, instead of having component scss with use statements that gets loaded as a text, what if we put the translation from scss-land into lit css template tags higher up, that is, in core, vars, etc. Then in component code we could simply import { vars } from './where/ever.js' and use them as normal in lit.

One reason for the structure you see here is that I was trying to follow the USWDS structure somewhat (note though that they have an ?inline query on their scss, which is used by Vite) --> https://github.com/uswds/uswds/blob/develop/packages/usa-banner/src/usa-banner.component.js#L5

Another approach could be to have an intermediary JS file that serves as a bridge between the component JS and the SCSS file. Kind of like what you see on https://lit.dev/docs/components/styles/#sharing-styles, but in that example button-styles.js would have the import styles from './cfpb-button.component.scss' that you currently see in cfpb-button/index.js. This would create an extra JS file per component, so for simplicity I opted to add the SCSS import directly in the component code.

[wpears]

I'm happy to go with this and if we encounter any friction we can adapt as needed. Nice work!

[anselmbradford]

Regular components /dist/ files are receiving uncompressed dupes of the web components code. Lemme know if you see why.

I figured this out. Internally within the DS packages, we had the convenience import of, e.g., import { BaseTransition, EventObserver } from '@cfpb/cfpb-design-system';. This imports from the main DS index file, which exports all public JS methods, including the web component code. This led to the web component code ending up in the other non-web component JS bundles. If we instead update the convenience imports to the actual locations of the JS methods, then the individual component bundles are scoped only to their immediate dependencies. See 09f0434

[anselmbradford]

I'm going to merge this and open a separate PR that tweaks the optimizations. cssnano appears to provide slightly better compression than postcss-minify, and also might be able to handle autoprefixer as well. It would also be nice to remove whitespace from the web component markup in the JS file. It doesn't matter too much right now, because the markup is minimal, but could make a bigger difference in more complex components in the future.