👍🎉 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.
Regarding Ledger Applications (Ledger Live Desktop, Ledger Live Mobile) we are only accepting bugfixes for the moment. There is a good chance that we will reject feature based PRs based on the fact that they do not fit our roadmap or our long-term goals.
Before submitting a pull request, please make sure the following is done:
- Fork the repository and create your branch from
develop
(check the git conventions for the naming of the branch). - Follow the main installation steps. (https://github.com/LedgerHQ/ledger-live#installation)
- Follow additional installation steps depending on which package you want to contribute to.
- Make your changes.
- If you’ve fixed a bug or added code that should be tested, add tests!
- If needed, wait for the translations to be provided by the third party service.
- Add an entry to the changelog (
pnpm changeset
). - Make sure that the code passes linter and type checks (
pnpm lint:fix
andpnpm typecheck
). - Make sure the code passes unit and end to end tests (
pnpm test
). - Cleanup your branch - unless it contains merge commits (perform atomic commits, squash tiny commits…).
- Profit!
We use the following git conventions for the ledger-live
monorepo.
Depending on the purpose every git branch should be prefixed.
feat/
when adding a new feature to the application or librarybugfix/
when fixing an existing bugsupport/
for any other changes (refactor, tests, improvements, CI…)
We use changesets to handle the versioning of our libraries and apps. A detailed guide is available on the wiki.
We use the standard Conventional Commits specification and enforce it using commitlint.
You can 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.
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 that have merge commit from other branches (sub-features) should merge their target into them to be kept up to date
- Fill-in the PR template.
- Write a full description of what your pull request is about and why it was needed.
- Add some screenshots or videos if relevant.
- For Ledger Employees: Add the JIRA issue number to link the issue with the PR.
- 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
).
We use a third party service called Smartling to automate and manage translations for the Ledger Live applications (Desktop and Mobile).
You can find these files at the following locations:
- Ledger Live Desktop:
apps/ledger-live-desktop/static/i18n/en/app.json
- Ledger Live Mobile:
apps/ledger-live-mobile/src/locales/en/common.json
Ledger provides the tools and resources you need to build on top of our platform. They are accessible in the Ledger Developer Portal.