Development

Development

How to work on Moonfin and get changes merged. For setting up a build, see Building from Source.

Developer notes

• Use Flutter stable and keep dependencies up to date. Releases are built with the version pinned in .github/workflows/build.yml, see Building from Source
• Validate changes with flutter analyze and flutter test before PRs
• Test playback and navigation flows on at least one target platform
• Prefer small, focused commits for easier review

Contributing guidelines

We welcome contributions to Moonfin. The short version is below, and the full guide, including how the pull request template drives labels and why not to run a project-wide formatter, is CONTRIBUTING.md in the repository.

1. Check existing issues before opening new ones.
2. Discuss major feature changes before implementation.
3. Follow existing code style and project conventions.
4. Test your changes on relevant platforms.
5. Keep PR scope focused and clearly documented.

Pull request process

1. Fork the repository.
2. Create a branch (git checkout -b feature/your-change).
3. Implement and test your changes.
4. Run static checks (flutter analyze) and the tests (flutter test).
5. Open a PR against main with context, screenshots/logs when useful, and test notes.

Every pull request to main builds all platforms and runs the analyzer and the test suites in CI. A bot comment on the PR shows how each part went and updates itself with every new commit, so check it before asking for a review.

Translations

Moonfin translations are managed on Weblate at translate.moonfin.io. Translation files under lib/l10n/ are owned by Weblate, so translated strings should be changed there rather than edited directly in a pull request.