The USDS website is built with:
Before getting started, install the following on your system:
see How to use staging environment
We recommmend that you use a Docker container to run the site as a development environment because of dependency and version collisions. This allows the site to run in a contained place, minimizing setup issues.
docker build -t usds-website . --no-cache
Run this command to have a local version on http://localhost:4080
.
docker run -p 4080:4000 --name usdsweb usds-website
If you want to make changes and have them update on the running container
we need to map the active source code in to the container with a volume mount and
expose the port for livereload. This should ensure that changes you make are being
mapped to the /app director and refresh on the running container. Note the volume mount syntax
for pwd
might be different on Windows or a non Bash shell.
docker run -p 4080:4000 -p 35729:35729 -v $(pwd):/app --name usdsweb usds-website
Builds staging Jekyll site using JEKYLL_ENV=staging
. Staging builds are used for temporary testing on cloud.gov. Do not deploy a staging build to GitHub pages.
Staging sites are one-off, per-user builds in a cloud.gov sandbox. Handy for testing and gathering feedback.
To create a cloud.gov staging build:
npm run build-staging
cf
(TODO: details here)cf push
If you haven't used cloud.gov before, you'll want to set up
A successful push will print a staging url next to routes
, ex: website-staging-foo-bar-ab.app.cloud.gov
. Visit the staging url to preview your build.
To compare current actual screenshots with the established base images: npm run visual-regression
.
When pages are intentionally changed, refresh the base images with npm run visual-refresh
. This creates/updates base images and a sitemap.json file
. Commit these along with the page changes.
A GitHub workflow automatically runs the regression script when a pull request targeting the staging
branch is created or updated. A summary of results will appear as a comment on the PR. If a refresh is needed, users can activate the refresh script by manually running the Visual regression tesing
Action and providing the PR number. New/updated base images will be added to the PR.
This website relies on Cypress and cypress-axe to identify page-level accessibility issues. Hopefully, the issues identified in this testing are caught earlier in the development process using a combination of a good accessibility linter such as axe-Linter and a browser plugin such as Microsoft Accessibility Insights. This type of testing is to catch any errors missed.
Currently, the tests are designed to test work as you develop locally. When you implement any changes in the UI, open the cypress e2e tests with npm run cypress:open
. These tests will inject the axe-core library into the page-level instance and run the accessibility API.
Once you open cypress, select e2e testing and select your browser for testing. At this point you may click on the individual page-level tests. This will open a browser instance directly to the test, cypress will render the whole page. Accessibility violations will be visible on the left of the browser instance.
Additional output is in the browser console, which you'll want to open. With the console open, you can now click on any of the issues in the test body, and learn more information about the error and how to resolve it.
The accessibility.cy.js file runs a loop through all the pages, which may prove useful for future accessibility testing. A developer could more fully integrate cypress-axe testing with the CICD build process -- breaking the build if any accessibility error is detected.
Additional Resources about Cypress-axe:
Tickets are in website-management. Board is (https://github.com/orgs/usds/projects/77/views/1).
NOTE: make tickets in website-management
not here.
We use USWDS version 3. Most of the styles are built off of v2.12.0, but the underlying framework is v3. The scss
is in assets/stylesheets/uswds
, with the entry of index.scss
. uswds-settings.scss
has custom variables and styles.scss
has custom scss.
Custom USWDS theme settings are declared in assets/stylesheets/uswds/_uswds-theme-*.scss
. Use these files to add or remove utilities, edit variables, or change how the design system builds.
After updating, make a new build or restart your localhost to see any changes.
To update a major version of uswds
, consult their documentation. The package.json
settings will allow for minor and patch updates as a matter of course.