@cmsgov/ds-healthcare-gov

A Site Package is a method for sharing common, site-specific, design and code resources between the various teams working on HealthCare.gov. These resources are unique to HealthCare.gov, and not generalized for inclusion in the Design System. It includes assets like design system overrides and site-specific components.

Usage

Installation

npm install --save @cmsgov/ds-healthcare-gov

Importing Sass

The source files included are written in Sass (.scss). You can add your node_modules directory to your Sass includePaths and import the file like below.

Note: The site package's Sass file imports the core, layout, and support design system Sass files as well, so the following is all you need to import to gain access to those resources:

@import '@cmsgov/ds-healthcare-gov/src/index';

Importing React components

For components distributed through the site package, you can import them like this:

import { Header } from '@cmsgov/ds-healthcare-gov';

Note: Ensure that you use a bundler with tree shaking enabled to avoid bundling unused components.

Contributing

Please view the CONTRIBUTING.md to read how you can add to the site package, as well as how to preview the site package in the context of the design system's documentation site.

File structure

├── dist
│   └── index.css                         Compiled CSS
├── src
    ├── components
    │   ├── Header
    │   │   ├── Header.jsx                Top-level <Header> component
    │   │   ├── defaultMenuLinks.js       Default menu links for each header variation
    │   └── index.scss                    Component Sass imports
    ├── locale
    │   ├── en.json                       English i18n strings
    │   ├── es.json                       Spanish i18n strings
    │   └── translate.js                  react-i18next initializer and HOC
    ├── index.scss                        Main Sass entry point with all imports
    └── settings
        └── _override.color.scss          Design system color variable overrides

---

Why a site package?

HealthCare.gov consists of multiple codebases maintained by different teams. App 3.0 lives in one repo maintained by Nava, Window Shop lives in a different repo maintained by Ad Hoc, and Plan Compare lives in yet another repo. Currently this means some design assets and code are duplicated across codebases, going against the software development principle to keep things DRY. These multiple codebases naturally tend to have differences, and as a result have caused inefficiencies and inconsistencies to creep into the user interface.

The Design System is one way we're addressing the issues mentioned above. However, the design system is meant to be used by many CMS (Centers for Medicare & Medicaid Services) websites, not just HealthCare.gov. As a result, the resources within the design system are not tied to a particular website.

Goals

The primary goal of the Site Package is to reduce the amount of duplicate instances of HealthCare.gov front-end components and design assets, and having a single source of truth which all teams can contribute to and use.

A secondary goal for the Site Package is for it to serve as an intermediate step in a component's journey to becoming a design system component. This gives the teams working on HealthCare.gov a space to share and iterate on components that at first appear to only have a use case on HealthCare.gov.

Non-goals

• The Site Package is not meant to be as robust or as large as the Design System. It should be as small as possible, and ideally all reusable components would be from the design system.
• The Site Package is not meant to serve as a resource for best practices or accessibility guidelines — that's the responsibility of the design system.
• The HealthCare.gov Site Package is not meant to be a solution for other CMS websites.

Additional links

• The original tech spec for Site Packages can be viewed in the Design System Confluence