e-QIP-prototype

README

e-QIP Prototype

To create the e-QIP questionnaire prototype, the project team is employing a user-centered design approach leveraging key principles from the U.S. Digital Services Playbook:

1. Understand what people need
2. Address the whole experience, from start to finish
3. Make it simple and intuitive

Table of contents

• Project Management
• Development
• Architectural diagram
• Additional
• Contributing

Project Management

The project team utilizes GitHub Issues to administer User Stories and Tasks, prioritized and tracked in a Kanban board. Higher-level and non-development tasks are tracked in a Trello board.

Development

Initial setup

Dependencies

• git
• docker
• docker-compose
• make

For more information on licenses and third-party source code, use a tool like this one.

Clone all things

Clone the repository and cd into it:

git clone https://github.com/18F/e-QIP-prototype
cd e-QIP-prototype

Then to develop locally, create a .env file:

cp .env.example .env

For more information on the various settings, examples, and values please refer to the configuration documentation.

Tests

To do the initial setup and ensure that all tests pass locally:

make

Pre-Commit Hooks

There are some pre commit hooks added using husky to run them. The pre-commit hooks are designed to run outside of docker for speed so you will need to have run yarn install outside the containers if you have not done so.

The hooks should automatically be applied once yarn install is complete, and will run the eslint and css lint rules on files changed that are staged for commit. Developers should apply lint fixes; however, specifiying --no-verify as an argument to git commit to bypass this check for temporary wip commits.

The eslint rules for the pre-commit hook will be using a stricter standard than the CI build to allow us to improve the code as we modify files while avoiding having to fix all the errors that would be generated if the rules were applied to the whole project immediately. Eventually we will want to apply the stricter rules to the CI build as well.

Feature Tests

Setup steps:

1. Edit .env file and set API_REDIRECT=http://web:8080 and API_BASE_URL=http://api:3000
2. Disable SAML_ENABLED auth and enable BASIC_ENABLED
3. Edit /etc/hosts file OPTIONAL add web and api to the end of the localhost line in /etc/hosts so you don't have to keep changing the values of API_REDIRECT or API_BASE_URL in .env file back to localhost
4. Run make run to ensure services are restarted
5. Run the purge directions from docs/test-scenarios.md to clear out old data

To run the feature specs locally:

make specs

Screenshots will be recorded in specs/screenshots

To run a single feature spec locally:

make specs COMMAND='bash -c "yarn run nightwatch --test features/identification.feature"'

Running a local server

To run a local server, we are using docker containers leveraging the docker-compose tool via the command:

make run

Then direct your browser at http://localhost:8080. The access the site in development use the username test01 and password password01. If you make changes to frontend files, the site will automatically rebuild after ~10 seconds.

How it works

The Make target calls Docker Compose, which then runs containers for various parts of the system. Frontend assets are built from their own containers into the dist/ folder, which are then served by nginx. There is also an API backend (under api/) written in Go, which has a PostgreSQL database behind it. See the architecture diagram below.

See also: frontend docs.

Architectural diagram

There are several possible architectures which may be implemented. The diagram references one of those possible solutions and highlights the basic flow of data within the system. It also demonstrates integration with external systems (e.g. identity services) which are not part of this project but may be part of the overall system.

Additional

See advanced docs for more.

Tooling

Formatting

Supported files are formatted using Prettier, though note this should only be done when a file is new or heavily modified. You should install Prettier for whatever editor you use.

Linters

• Vim users: install syntastic
• Emacs users: install flycheck

For command-line alternatives there are the following:

• For CSS, run make lint-css
• For JavaScript, run make lint-js
• For HTML, html-lint which may be installed with yarn add html-lint

Contributing

Please refer to the contributing documentation.