Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
40 lines (24 loc) · 3.58 KB

CONTRIBUTING.md

File metadata and controls

40 lines (24 loc) · 3.58 KB

Contributing to DCB Admin

Contributors should be aware of the following when contributing to DCB Admin.

Standards

Contributions to DCB Admin must meet the following standards, most of which have been taken from our DCB Definition of Done:

  • Your contribution must have accompanying tests (if required by the original issue), and must be manually tested before submitting.

  • All defined acceptance criteria must have been met, as well as any other criteria (i.e. accessibility). These are usually defined on the corresponding JIRA ticket. Checking that the criteria have been met is the 'manual testing' referred to previously.

  • Commit messages should be in conventional format (see the Angular guidelines). If you're curious about this, check the other commits to the project. We typically attach the JIRA ticket number to the end of the commit message for reference.

  • The AXE Dev Tools must be run against all pages affected by the changes, and any accessibility issues must be fixed before contributions are submitted for review. We follow the WCAG 2.1 accessibility guidelines, which can be found here. The Chrome extension for the AXE Dev Tools can be found here https://chromewebstore.google.com/detail/axe-devtools-web-accessib/lhdoppojpmngadmnindnejefpokejbdd?pli=1 .

  • Any relevant scripts and technical documentation should be updated.

  • Tests should be run before submitting an MR, and any failures must be addressed before submitting. If you run into failures that you're not sure about, please submit your MR as a draft so that others can assist you.

  • This also applies to the pre-commit hooks. Do not skip these or add 'ignore' statements without clear justification. It is also recommended that you run npm run build before submitting your changes, to catch potential build failures.

  • A link to a screen capture or a link to a Vercel preview branch should be added to the MR. This aids QA, and makes potential changes more visible, so people can see what you've changed.

Formatting

DCB Admin uses Prettier for code formatting. Please install the Prettier extension in your editor and, if using VS Code, set Prettier as your default formatter and enable 'format on save'. If you're having issues, Ctrl-Shift-P, open your user settings, and ensure Prettier is set as editor.defaultFormatter and that editor.formatOnSave is also enabled.

Linting

DCB Admin uses ESLint with TypeScript ESLint tooling and the recommended TypeScript ESLint configuration. Our ESLint setup also includes JSX a11y for accessibilty linting and eslint-config-next.

To run ESLint, please run the command npm run lint . For automatic linting, please ensure you have the ESLint extension installed in VS Code. You can also configure your settings like so to have ESLint run on save:

"editor.codeActionsOnSave": {
		"source.fixAll.eslint": "explicit"
},

Pre-commit checks

DCB Admin uses a pre-commit Git hook, implemented with Husky and lint-staged to run Prettier and ESLint on staged items and catch common issues before they are committed. If issues that can't be automatically fixed are present, the pre-commit hook will point you in the right direction.