Skip to content

Latest commit

 

History

History
123 lines (76 loc) · 4.97 KB

CONTRIBUTING.md

File metadata and controls

123 lines (76 loc) · 4.97 KB
Raw

Contributing

👍🎉 First off, thanks for taking the time to contribute! 🎉👍

This file will guide you through the local setup and contains the guidelines you will need to follow to get your code merged.

Disclaimer

While you explore these projects, here are some key points to keep in mind:

  • Follow the git workflow, prefix your branches and do not create unnecessary merge commits.
  • Be mindful when creating Pull Requests, clearly specify the purpose of your changes and include tests where applicable.
  • Device Management Kit is mostly accepting bugfix contributions. Feature contributions are subject to review; they may be declined if they don't align with our roadmap or our long-term objectives.

Guidelines

Important Steps

Before submitting a pull request, please make sure the following is done:

  1. Fork the repository and create your branch from develop (check the git conventions for the naming of the branch).
  2. Follow the main installation steps. (https://github.com/LedgerHQ/device-sdk-ts#getting+started)
  3. Follow additional installation steps depending on which package you want to contribute to.
  4. Make your changes.
  5. If you’ve fixed a bug or added code that should be tested, add tests!
  6. Add an entry to the changelog (pnpm changeset).
  7. Make sure that the code passes linter and type checks (pnpm lint:fix and pnpm typecheck).
  8. Make sure that the code passes the prettier checks.
  9. Make sure the code passes unit and end to end tests (pnpm test).
  10. Cleanup your branch - unless it contains merge commits (perform atomic commits, squash tiny commits…).

Git Conventions

We use the following git conventions for the Device Management Kit monorepo.

Branch naming

Depending on the purpose every git branch should be prefixed.

  • feat/ / feature/ Add a new feature to the application or library
  • bugfix/ / bug/ / fix/ Fixing an existing bug
  • support/ For any other changes (tests, improvements, CI…) For Ledger Employees:
  • chore/ / core/ For maintenance work on the repo
  • doc/ Add or modify documentation
  • refacto/ / refactor/ Modify the code organisation

For Ledger Employees only: Add the Jira ticket number DSDK-<number> (case insensitive) or NO-ISSUE if not applicable.

If resolving a Github issue (optional and not to be combined with Jira ticket number): add ISSUE-<number>

Followed by a small description.

Examples:

User type Ticket Example
employee yes feature/dsdk-350-add-sparkles
employee no refacto/no-issue-remove-sparkles
contributor yes feat/issue-37-add-new-transport
contributor no fix/missing-dependencies

Changelogs

We use changesets to handle the versioning of our libraries and apps. A detailed guide is available on the wiki.

Commit message

We use the standard Conventional Commits specification and enforce it using commitlint.

The format is similar to gitmoji:

():

  • scope is the module/package that is impacted by the update.
  • <description> should start with an uppercase.

You should use the pnpm commit prompt to ensure that your commit messages are valid, as well as the pnpm commitlint --from <target branch> command to check that every commit on your current branch are valid.

Rebase & Merge strategies

The rule of thumb is to always favour rebasing as long as your branch does not contain merge commits.

For instance:

  • bugfix branches that are small and self-contained should always get rebased on top of develop.
  • feature branches should always get rebased on top of develop.

Pull Request Conventions

Follow the next step to fill the PR template

Title

The description format is similar to gitmoji:

() [NO-ISSUE]:

  1. scope is the module/package that is impacted by the update (should be the same than the commit ones).

  2. For Ledger Employees: NO-ISSUE to be replace by DSDK-<number> or ISSUE-<number> in case of tracking

  3. <description> should start with an uppercase.

Description

  • Write a full description of what your pull request is about and why it was needed.
  • Add some screenshots or videos if relevant.
  • Do not forget to fill the checklist

Workflow

  • Github actions will trigger depending on which part of the codebase is impacted.
  • Your PR must pass the required CI actions.
  • Your PR must include a changelog (pnpm changeset), except for tools and maintenance operations.

For external contributors: a member of the Ledger will be required to validate the execution of the CI for external contributions

Developer Portal

Ledger provides the tools and resources you need to build on top of our platform. They are accessible in the Ledger Developer Portal.