The following guidelines must be followed by all contributors to this repository. Please review them carefully and do not hesitate to ask for help.
- Review and test your code before submitting a pull request.
- Be kind and professional. Avoid assumptions; oversights happen.
- Be clear and concise when documenting code; focus on value.
- Don't commit commented code to the main repo (stash locally, if needed).
See our code of conduct for more details.
Clone and Install One App:
export NODE_ENV=development
git clone https://github.com/americanexpress/one-app.git
cd one-app
npm i --no-optional
At this point depending on what contribution you are looking to make you may wish to create a sample
module to demostrate your new feature, develop against, and ultimately run integration tests
against. The most efficient way to do so is to copy one of the existing sample modules
(prod-sample/sample-modules/frank-lloyd-root/0.0.0
), and use that as your root module.
For more details on this see the sample modules documentation:
cd prod-sample/sample-modules/<your-newly-created-module>/0.0.0
npm ci
cd ../../../..
npm run serve-module prod-sample/sample-modules/<your-newly-created-module>/0.0.0
export ONE_CLIENT_ROOT_MODULE_NAME=<your-newly-created-module>
If there is an existing sample module that makes sense for you to use as you develop your feature and write integration tests then use that instead.
cd prod-sample/sample-modules/<an-existing-module>/0.0.0
npm ci
cd ../../../..
npm run serve-module prod-sample/sample-modules/<an-existing-module>/0.0.0
export ONE_CLIENT_ROOT_MODULE_NAME=<an-existing-module>
Start One App:
npm run start:watch
We use Jest as the test runner for all our tests and
ESLint for linting. Prior to opening a pull request make sure to run
npm test
. This requires Docker to be installed.
To run the unit tests, integration tests, and linting:
$ npm test
If you would like to run only the unit tests:
npm run test:unit
Or only the integration tests:
npm run test:integration
Or only linting:
npm run test:lint
To auto fix eslint rule failures that are autofixable run npm run test:lint -- --fix
- Fork the One App repository, open a PR to
main
, and follow the guidelines outlined in this document.
-
Keep PRs small, there should be one change per pull request.
-
All pull requests must have descriptions and a link to corresponding issue(s) if applicable.
-
Be sure to answer all the questions in our preflight checklist. There should be a comment from Danger in the pull request asking for this checklist to be filled out.
-
Keep commit history clean. Follow commit message guidelines (see below) and squash commits as needed to keep a clean history. Remember that your git commit history should tell a story that should be easy to follow for anyone in the future.
-
Before making substantial changes or changes to core functionality and/or architecture open up an issue to propose and discuss the changes.
-
Be patient. The review process will be thorough. It must be kept in mind that changes to our repos are platform wide and thus are not taken lightly. Be prepared to defend every single line of code in your pull request. Attempting to rush changes in will not work.
-
Write tests for your changes. A feature is not considered done until it has tests and/or a test plan. It does not matter if code coverage shows 100%, tests are expected for all changes. This includes integration tests as needed.
The One App community can be found on GitHub Discussions, where you can ask questions, voice ideas, and share your projects.
We follow precise rules for git commit message formatting. These rules make it easier to review commit logs and improve contextual understanding of code changes. This also allows us to auto-generate the CHANGELOG from commit messages and automatically version One App during releases.
For more information on the commit message guidelines we follow see conventional commits.