[WIP-03] [Project Solar / Phase 1 / Themed CSS for HDS components] Rollup configuration and Sass processing for multiple files

[didoo]

:pushpin: Summary

This is built on top of https://github.com/hashicorp/design-system/pull/3239 and is based on the initial spike done by @alex-ju in https://github.com/hashicorp/design-system/pull/3235

:hammer_and_wrench: Detailed description

In this PR I have:

• re-organized the components' Sass files architecture to split the common part in a separate file, and add two new Sass files that include theming via CSS selectors or via prefers-color-scheme
• update the Rollup configuration to process multiple Sass files and generate distinct CSS files in output:
  • design-system-components.css - current file for HDS components
  • design-system-components-theming-with-css-selectors.css - new file for theming via CSS selectors
  • design-system-components-theming-with-prefers-color-scheme.css - new file for theming via prefers-color-scheme

Then, after discussion and agreement with @alex-ju, I have moved also the existing compilation of the design-system-components.scss and design-system-power-select-overrides.scss files to our custom plugin, so we can remove rollup-plugin-scss as dev-dependency

• in the new configuration, the design-system-power-select-overrides.scss is not only copied in the dist folder, but also compiled to .css (and a .map file is generated)

🔎 How to review

You can look at the single commits, to see the sequence of steps and understand the explorations and thinking behind the PR, or you can look directly at the files, checking how the Scss files have been organized, how the Rollup plugin function has been implemented, and how the path for the include declarations have been updated to make it more obvious where a file was coming from.

🛠️ How to test

Check out the branch, delete the dist folder under packages/components, run the command pnpm build or pnpm start, and see how different files are copied/generated under packages/components/dist/styles/@hashicorp (source Scss files, compiled CSS files, map files)

You can also go one step further, and update (or add) some design tokens with $modes values, run the pnpm build command in the packages/tokens folder, and then run the command pnpm build in the packages/components folder and see how the tokens changes are reflected in the generated CSS files for the components (if only $modes are changed, the file packages/components/dist/styles/@hashicorp/design-system-components.css should remain untouched.

💬 To discuss/decide

• [ ] would it make sense to have a "normal" CSS compiled for the "old" components, as is now, made of the "standard" non-themed files, and instead of compiling three different compiled "themed" CSS file, have only one for the components Scss code (it doesn't need the tokens CSS to compile!) and consumers import the "themed" CSS file they want, depending on which type of theming implementation they want to use
  • [ ] Per Copilot review: "Using @use with a .css file extension is invalid in Sass. The @use rule should import .scss files, not .css files. Either change the file extension to .scss or use @import instead.
    • - @use "products/css/themed-tokens/with-prefers-color-scheme/tokens.css";
    • + @import "products/css/themed-tokens/with-prefers-color-scheme/tokens.css";

🔗 External links

Jira ticket: https://hashicorp.atlassian.net/browse/HDS-5505

---

:eyes: Component checklist

• [x] Percy was checked for any visual regression
• [ ] ~~A changelog entry was added via Changesets if needed (see templates here)~~
  • changelogs will be added in the main feature branch

:speech_balloon: Please consider using conventional comments when reviewing this PR.

:clipboard: PCI review checklist

• [ ] If applicable, I've documented a plan to revert these changes if they require more than reverting the pull request.
• [ ] If applicable, I've worked with GRC to document the impact of any changes to security controls. Examples of changes to controls include access controls, encryption, logging, etc.
• [ ] If applicable, I've worked with GRC to ensure compliance due to a significant change to the in-scope PCI environment. Examples include changes to operating systems, ports, protocols, services, cryptography-related components, PII processing code, etc.

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Updated (UTC)
hds-showcase	Ready	Preview	Nov 25, 2025 4:59pm
hds-website	Ready	Preview	Nov 25, 2025 4:59pm

[KristinLBradley]

In packages/components/dist/styles/@hashicorp, the copyright in "design-system-components-common.css" and in "design-system-components.css" ends up below the first line of code. Probably not a big deal but it looks a little strange and causes the linter to complain about spacing.

In "design-system-power-select-overrides.css" and "design-system-power-select-overrides.scss" There's this linter complaint:

the linter also complains about spacing between style rules in "design-system-power-select-overrides.css" being absent.

[didoo]

In packages/components/dist/styles/@hashicorp, the copyright in "design-system-components-common.css" and in "design-system-components.css" ends up below the first line of code. Probably not a big deal but it looks a little strange and causes the linter to complain about spacing.

In "design-system-power-select-overrides.css" and "design-system-power-select-overrides.scss" There's this linter complaint:

the linter also complains about spacing between style rules in "design-system-power-select-overrides.css" being absent.

@KristinLBradley these are compiled files, there's not much we can do (as you mentioned, they're generated in the dist folder of packages/components)