Contributing to Arizona
View SourceSetup
See .tool-versions for required Erlang/OTP and Node versions.
git clone https://github.com/arizona-framework/arizona.git
cd arizona
npm install
make compile
Workflow
Two commands cover day-to-day development:
make precommit-- run before every commit. Formats Erlang/JS, recompiles, runs the fast checks (Erlang format check plus the JS lint/type checks), and runs the Erlang + JS unit test suites. Skips Elvis lint, hank, xref, Dialyzer, and E2E for speed.make ci-- run before pushing. The full pipeline: adds Elvis lint, hank, xref, Dialyzer, coverage, E2E, and docs on top of what precommit covers. CI re-runs it on the PR.
For everything else (single-suite runs, coverage reports, individual
check stages, doc generation, etc.) see the targets in the project's
Makefile.
The native (?native) Android client lives in-repo at clients/android/
(Kotlin/Compose, its own Gradle build). It is not part of make ci; build
it with make build-android and run its tests with make test-android (needs
the Android SDK + an emulator/device). Its CI runs separately via the
android-e2e workflow. See docs/native.md.
The native iOS client lives in-repo at clients/ios/ (Swift/SwiftUI). Its
protocol logic is a Swift package you can test on any platform with swift test
(no Mac needed); the SwiftUI render + XCUITest e2e need macOS + Xcode +
xcodegen (brew install xcodegen). Build with make build-ios and test with
make test-ios; like the Android client it is not part of make ci and has
its own ios-e2e workflow.
License
Arizona is licensed under the Apache License Version 2.0, for all code.
Reporting a bug
Arizona is not perfect software and will be buggy.
Bugs can be reported via GitHub issues: bug report.
Some contributors and maintainers may be unpaid developers working on Arizona, in their own time, with limited resources. We ask for respect and understanding, and will provide the same back.
If your contribution is an actual bug fix, we ask you to include tests that, not only show the issue is solved, but help prevent future regressions related to it.
Requesting or implementing a feature
Before requesting or implementing a new feature, do the following:
- search, in existing issues (open or closed), whether the feature might already be in the works, or has already been rejected,
- make sure you're using the latest software release (or even the latest code, if you're going for bleeding edge).
If this is done, open up a GitHub issues: feature request.
We may discuss details with you regarding the implementation, and its inclusion within the project.
We try to have as many of Arizona's features tested as possible. Everything that a user can do, and is repeatable in any way, should be tested, to guarantee backwards compatible.
Submitting your changes
Code Style
- do not introduce trailing whitespace
- indentation is 4 spaces, not tabs
- try not to introduce lines longer than 100 characters
- write small functions whenever possible, and use descriptive names for functions and variables
- comment tricky or non-obvious decisions made to explain their rationale
Committing your changes
Merging to the main branch will usually be preceded by a squash.
While it's Ok (and expected) your commit messages relate to why a given change was made, be aware that the final commit (the merge one) will be the issue title, so it's important it is as specific as possible. This will also help eventual automated changelog generation.
Pull requests and branching
All fixes to Arizona end up requiring a +1 from one or more of the project's maintainers.
During the review process, you may be asked to correct or edit a few things before a final rebase to merge things. Do send edits as individual commits to allow for gradual and partial reviews to be done by reviewers.
Credits
Arizona has been improved by many contributors!