build_and_development_commands:
- Run `flutter pub get` after cloning or adding packages.
- Run `flutter pub run build_runner build --delete-conflicting-outputs` to generate files.
- Debug build: `flutter run`
- Release build:
android: `flutter build apk --release`
ios: `flutter build ios --release`
web: `flutter build web`
- Clean build cache: `flutter clean`
- Use environment-specific configurations via `.env` or Flutter flavors.
- Automate build tasks using CI/CD (GitHub Actions, Codemagic, Bitrise).
testing_guidelines:
unit_tests:
- Use `test` package.
- Mock dependencies with `mocktail` or `mockito`.
- Keep logic pure and testable.
widget_tests:
- Use `flutter_test` and `WidgetTester`.
- Test rendering and user interaction.
integration_tests:
- Use `integration_test` package.
- Write end-to-end flows for user scenarios.
coverage:
- Run all tests: `flutter test`
- Generate coverage report: `flutter test --coverage`
code_style_and_guidelines:
linting:
- Use `flutter_lints` or `very_good_analysis`.
architecture:
- Follow Clean Architecture.
- Organize code by feature.
state_management:
- Use one approach per app: Riverpod, Bloc, or Provider.
naming_conventions:
class: PascalCase
variable: camelCase
constant: SCREAMING_SNAKE_CASE
widgets:
- Keep widgets small and composable.
- Extract complex widgets into separate files.
formatting:
- Use `dart format .` before committing.
general_rules:
- No hardcoded strings or styles.
- Use logger instead of `print()`.
- Remove all debugging code before release.
documentation_guidelines:
readme:
- Overview of the project.
- Setup and install instructions.
- Folder structure.
- Architecture and state management.
- How to run and test.
code_comments:
- Use `///` for public classes and methods.
- Describe purpose, parameters, and return types.
changelog:
- Maintain `CHANGELOG.md` with versioned updates.
internal_docs:
- Add `/docs` folder for architecture diagrams or API flowcharts.
generated_docs:
- Use `dart doc` for generating reference documentation.