Skip to content

Latest commit

 

History

History
93 lines (68 loc) · 4.51 KB

CONTRIBUTING.md

File metadata and controls

93 lines (68 loc) · 4.51 KB
Raw

Contributing Guidelines

Thank you for your interest in contributing to our project! 💛

Please read through these guidelines carefully before submitting a PR and let us know if it's not up to date (or even better, submit a PR with your corrections 😉).

Table of Contents

Bug Reports

Bug reports and feature requests are always welcome. Good bug reports are extremely helpful, so thanks in advance!

When filing a bug, please try to be as detailed as possible. In addition to the bug report form information, details like these are incredibly useful:

  • A reproducible test case or series of steps
  • The date/commit/version(s) of the code you're running
  • Any modifications you've made relevant to the bug
  • Anything unusual about your environment or deployment

Guidelines for bug reports:

  • Check to see if a duplicate or closed issue already exists!
  • Provide a short and descriptive issue title
  • Remove any sensitive data from your examples or snippets
  • Format any code snippets using Markdown syntax

Finally, thank you for taking the time to read this, and taking the time to write a good bug report.

Pull Requests

We welcome pull requests!

You should open an issue to discuss your pull request, unless it's a trivial change. It's best to ensure that your proposed change would be accepted so that you don't waste your own time. If you would like to implement support for a significant feature that is not yet available, please talk to us beforehand to avoid any duplication of effort.

Contribution Process

  1. Fork & Clone this repo
  2. nvm install
  3. nvm use
  4. yarn setup
  5. Within your fork, create a new branch based on the issue you're addressing -- git checkout -b angular/remove-browser-module
  6. Once your work is committed, validate your changes according to local development guides.
  7. Push your branch with git push origin -u
  8. Open a PR against this repo from your newly published branch.
  9. Add a changeset that describes your changes. More info here. Please make sure that your changeset only bumps @aws-amplify/* packages and does not bump any of private packages like docs, e2e, examples, etc.
  10. Finally, Amplify UI team will review your PR. Add reviewers based on the core member who is tracking the issue with you or code owners. In the meantime, address any automated check that fail (such as linting, unit tests, etc. in CI)

Project Structure

amplify-ui is a monorepo that contains the following workspaces:

amplify-ui
├── canary # contains examples we use to test build systems
├── docs # ui.docs.amplify.aws documentation code
├── environments # Amplify backend environments we use for e2e testing
├── examples # Example apps we use for e2e testing
│   └── angular
│   └── next
│   └── vue
├── packages # Amplify UI components implementations
│   └── angular
│   └── react
│   └── vue

Local Devleopment Guides

Please refer to the following contributing guides:

Publishing

Amplify UI team publishes to NPM on every Tues (mandatory) and Thurs (optional). We use changesets to drive our deployment procedure:

  1. Each contributor adds a changeset in their PR
  2. Changesets get accumulated into Version Packages PR.
  3. Maintainer will run tests, approve, and merge the PR.
  4. Previous step will trigger publish-latest action that will build and publish packages to NPM.