Contributing to LuCI Mobile
Relevant source files
The following files were used as context for generating this wiki page:
Contributing to LuCI Mobile involves following a structured development workflow to maintain the quality of the Flutter-based OpenWrt management client. This guide outlines the environment setup, coding standards, and the process for submitting changes to the repository.
Sources: CONTRIBUTING.md:1-12, README.md:1-15
Development Environment Setup
LuCI Mobile requires the Flutter SDK and specific router modules to function correctly. You must use Flutter version 3.8.1 or higher.
Prerequisites and Dependencies
The project uses several key Flutter packages for functionality, including flutter_riverpod for state management and dio for network requests.
| Category | Requirement / Dependency |
|---|---|
| SDKs | Flutter (>= 3.8.1), Dart SDK |
| Tools | Git, IDE (VS Code, Android Studio, or IntelliJ) |
| State Management | flutter_riverpod: ^3.4.2 |
| Networking | dio: ^5.4.0 |
| Storage | flutter_secure_storage: ^11.0.0 |
Sources: CONTRIBUTING.md:15-22, pubspec.yaml:27-52
Router Configuration
To test features, your OpenWrt router requires specific RPC modules. Execute these commands on the router to enable compatibility:
opkg update
opkg install rpcd-mod-luci rpcd-mod-iwinfo
/etc/init.d/rpcd restart
Sources: README.md:92-101
Workflow and Standards
The project enforces strict coding styles and testing requirements to ensure stability across multiple router configurations.
Coding Standards
Contributors must follow the official Dart Style Guide and use the project's static analysis configuration. The analysis_options.yaml file defines critical rules for resource management and security.
- Naming: Use
snake_casefor files,PascalCasefor classes, andcamelCasefor variables and constants. - Static Analysis: Run
flutter analyzeto catch issues. CI configurations treat fatal infos as build failures. - Formatting: Format all code using
dart format ..
Sources: CONTRIBUTING.md:65-85, analysis_options.yaml:41-55
Pull Request Process
The following diagram illustrates the sequence from creating a feature branch to merging a Pull Request.
This process ensures that code is verified locally before reaching the main repository.
Sources: CONTRIBUTING.md:90-130
Testing and Quality Assurance
Testing is mandatory for all new features and bug fixes to prevent regressions in network management logic.
Test Categories
- Unit Tests: Validate individual functions and logic components.
- Integration Tests: Verify API communication with LuCI RPC and authentication flows.
- Manual Testing: Check performance and UI on physical devices or emulators.
Sources: CONTRIBUTING.md:173-195
Automated Verification Commands
Use these commands to verify your changes:
# Run all unit and widget tests
flutter test
# Run tests with coverage reporting
flutter test --coverage
# Perform static analysis
flutter analyze
Sources: CONTRIBUTING.md:197-206, README.md:86-89
Release and Versioning
The project follows Semantic Versioning (SemVer) and uses a CI-driven release process triggered by a dedicated script.
Release Workflow
The scripts/release.sh script automates version bumping and tagging.
The script increments the build number in pubspec.yaml and pushes a new tag to GitHub to trigger automated builds.
Sources: scripts/release.sh:17-105, CONTRIBUTING.md:231-240
Version Structure
The versioning follows the MAJOR.MINOR.PATCH+BUILD format defined in the project configuration.
Sources: pubspec.yaml:18-24, scripts/release.sh:42-65
Contributing to LuCI Mobile requires adherence to Dart standards, mandatory testing, and a specific release workflow to ensure the mobile client remains a reliable tool for OpenWrt management.