department-of-veterans-affairs / vets-website

VA.gov Table of Contents • VA.gov • Table of Contents • What is this? • Common commands • Building • Building applications • Building static content • Building both together • Working in GitHub Codespaces • Running tests • Unit tests • End-to-end (E2E) / Browser tests • Debugging Node 22 CI failures • Running a mock API for local development • Option 1: MSW browser mocking (recommended for new work) • Option 2: mocker-api (legacy) • More commands • Supported Browsers • API Keys • Additional Resources • Not a member of the repository and want to be added? What is this? This is the front end repository for VA.gov. It contains application code used across the site. There are several repositories that contain the code and content used to build VA.gov. If you're looking to get started running VA.gov locally, you should read the Getting Started documentation. Common commands Once you have the site set up locally, these are some common commands you might find useful: | I want to... | Then you should... | | :------------------------- | :------------------------------------------------------------ | | fetch all dependencies | ; run this any time changes | | build applications | | | run the webpack dev server | | | build in codespaces | . Build with codespace options | Building Building applications uses Webpack to bundle application assets. To **build all applications**, run the following: To **build one or more applications**, you can use the option: To **recompile your application when you make changes**, run: Stylelint is disabled by default in watch to improve performance. To enable it, pass: You can also **limit the applications Webpack builds** with : The for your application can be found in its file. If you're developing a feature that requires the API, but can't or don't want to run it locally, you can specify : You will need to disable CORS in your browser when using a non-local API. Here are some helpful links that explain how to do this: • https://stackoverflow.com/questions/3102819/disable-same-origin-policy-in-chrome • https://stackoverflow.com/questions/4556429/disabling-same-origin-policy-in-safari **Note:** If you try to log on, ID.me will redirect you to the environment that the API is set up for. So in the above example, you'd be **redirected back to dev.va.gov.** Building static content Static pages are created from the content-build repository. See the building static content documentation. Building both together After building the applications, running in the directory will build content using the generated app bundles from . The full build can be seen in . Working in GitHub Codespaces Read the Codespaces documentation for this repository. Running tests Unit tests To **run all unit tests**, use: If you want to **run only one test file**, you can provide the path to it: To **run all tests for a folder in src/applications**, you can use app-folder: To **run all tests in a directory**, you can use a glob pattern: To **run tests with stack traces**, pass log-level : To **run tests with coverage output**, you can pass the coverage option: To **run tests with coverage and open the coverage report in your browser for a specific app** from : For **help with test runner usage**, you can run: End-to-end (E2E) / Browser tests • E2E or browser tests run in Cypress. **Before running Cypress tests**, first make sure that: • is served locally on port 3001 • You can do this with • is **NOT** running • Any required APIs will be mocked by the Cypress test that needs them. To **open the Cypress test runner UI and run any tests within it**: To **open the Cypress test runner UI in Codespaces and run any tests within it**: Then visit http://localhost:6080/ and log in with the password . To **run Cypress tests from the command line**: To **run specific Cypress tests from the command line**: To **run Cypress tests from the command line on a specific browser**: To **run Cypress tests with reports** Examples: • • Afterward, check contents. **For other options with ,** the same options for are applicable. Debugging Node 22 CI failures If your PR passes tests locally but fails the Node 22 compatibility check in CI, you can reproduce the issue locally: **Note:** The Node 22 branch uses happy-dom instead of jsdom, which can cause different behavior in tests, particularly with sessionStorage, web components, and async operations. Running a mock API for local development Option 1: MSW browser mocking (recommended for new work) MSW (Mock Service Worker) intercepts API requests directly in the browser — no separate server process needed. Define your mock handlers in your app, then run: See for full setup instructions, available mock data, and troubleshooting. Option 2: mocker-api (legacy) In separate terminal from your local dev server, run See the mocker-api usage documentation for how to use the . **If you need to log in**, go to your browser dev tools console and enter and refresh the page. This will then trigger a call, which will then get the mocked response of a logged-in user. (Assuming you've mocked that response, of course.) Responses to common API requests, such as and , you can use More commands After a while, you may run into a less common task. We have a lot of commands for doing very specific things. | I want to... | Then you should... | | :---------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | build the production site (dev features disabled). | | | deploy the production site (dev features disabled). | | | reset local environment (clean out node modules, Babel cache, and runs ) | | | run the app pages on the site for local development | | | run…