To start contributing to SumUp Open Source projects, please accept our Contributor License Agreement. Should you have any questions or concerns, please get in touch with [email protected].
We want to foster an inclusive and friendly community around our Open Source efforts. Like all SumUp Open Source projects, this project follows the Contributor Covenant Code of Conduct. Please, read it and follow it.
If you feel another member of the community violated our CoC or you are experiencing problems participating in our community because of another individual's behavior, please get in touch with our maintainers. We will enforce the CoC.
- Check existing issues and verify that your issue is not already submitted. If a similar issue already exists, we highly recommend to add your report to that issue.
- Open issue
- Be as detailed as possible - include the Node version, what you did, what you expected to happen, and what actually happened.
- Find an existing issue to work on or follow
Submitting an issue
to create one that you're also going to fix. Make sure to notify that you're working on a fix for the issue you picked. - Branch out from latest
main
. - Code, add, commit and push your changes in your branch.
- Make sure that tests and linter(s) pass locally for you.
- Submit a PR.
- Collaborate with the codeowners/reviewers to merge this in
main
.
- Continuously transpile and typecheck the code:
npm run dev
- Continuously run the tests:
npm run test
- Run the linter:
npm run lint
Make sure that you use Node v20.14 exactly, otherwise, the unit tests will probably fail. Node's localisation data for the Intl.NumberFormat
API tends to change between minor versions.
@sumup-oss/intl
follows semantic versioning. In short, this means we use patch versions for bugfixes, minor versions for new features, and major versions for breaking changes.
@sumup-oss/intl
uses changesets to do versioning. A changeset is a piece of information about changes made in a branch or commit. It holds three bits of information:
- What needs to be released
- What version the packages should be released at (using a semver bump type)
- A changelog entry for the released packages
Refer to the official documentation for more information.
We have a couple of special branches that are used for stable releases and pre-releases.
main
- The code in themain
branch is stable and production-tested. When a PR is merged tomain
that contains a new changeset,changesets
opens a PR and keeps it up to date with the latest changes. When the PR is merged, a new version is automatically published to NPM and the changesets since the last release are added toCHANGELOG.md
files in GitHub.canary
- This is a branch you can use to publish a prerelease version if you need to deploy the changes somewhere to test them.canary
is a throw-away branch that can be recreated frommain
at any time. Hint: If you only need to test your changes locally, you can usenpm install ./path-to-foundry
to link the development version.next
— This branch is used to develop the next major version in parallel. It is the only branch that can contain breaking changes.
To install the most recent version from a release channel in your project, run:
npm install --dev @sumup-oss/intl@<release-channel>
Pre-releases can be done for either the next
or the canary
release channels.
To publish a pre-release version, check out on the branch for your release channel and run the changesets pre enter
command:
git checkout next # or `canary`
npx changeset pre enter next # or `canary`
This will generate a pre.json
file in the .changeset
directory.
Push it to the branch, then verify and merge the changesets
"Version Package" PR for your release channel. changesets
will publish the pre-release version in CI.