Merge branch 'master' into modular_5

Author: jacobaraujo7

.github/pull_request_template.md

@@ -0,0 +1,37 @@
+# Description
+
+<!-- Provide a description of what this PR is doing. 
+If you're modifying existing behavior, describe the existing behavior, how this PR is changing it,
+and what motivated the change. If this is a breaking change, specify explicitly which APIs have been
+changed. -->
+
+## Checklist
+
+<!-- Before you create this PR confirm that it meets all requirements listed below by checking the
+relevant checkboxes (`[x]`). This will ensure a smooth and quick review process. -->
+
+- [ ] The title of my PR starts with a [Conventional Commit] prefix (`fix:`, `feat:`, `docs:` etc).
+- [ ] I have read the [Contributor Guide] and followed the process outlined for submitting PRs.
+- [ ] I have updated/added tests for ALL new/updated/fixed functionality.
+- [ ] I have updated/added relevant documentation in `docs` and added dartdoc comments with `///`.
+- [ ] I have updated/added relevant examples in `examples`.
+
+## Breaking Change
+
+<!-- Does your PR require Modular users to manually update their apps to accommodate your change? 
+
+If the PR is a breaking change this should be indicated with suffix "!"  (for example, `feat!:`, `fix!:`). See [Conventional Commit] for details.
+-->
+
+- [ ] Yes, this is a breaking change.
+- [ ] No, this is *not* a breaking change.
+
+## Related Issues
+
+<!-- Provide a list of issues related to this PR from the [issue database].
+Indicate which of these issues are resolved or fixed by this PR, i.e. Fixes #xxxx* !-->
+
+<!-- Links -->
+[issue database]: https://github.com/Flutterando/modular/issues
+[Contributor Guide]: https://github.com/Flutterando/modular/blob/main/CONTRIBUTING.md
+[Conventional Commit]: https://conventionalcommits.org

.github/workflows/title-validation.yml

@@ -0,0 +1,14 @@
+name: title-validation
+
+on:
+  pull_request:
+    types: [opened, reopened, synchronize]
+
+jobs:
+  validate-pr-title:
+    name: Validate PR title
+    runs-on: ubuntu-latest
+    steps:
+      - uses: amannn/action-semantic-pull-request@v4
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

CONTRIBUTING.md

@@ -0,0 +1,124 @@
+# Contribution Guidelines
+
+**Note:** If these contribution guidelines are not followed your issue or PR might be closed, so
+please read these instructions carefully.
+
+## Contribution types
+
+### Bug Reports
+ - If you find a bug, please first report it using [Github issues].
+   - First check if there is not already an issue for it; duplicated issues will be closed.
+
+### Bug Fix
+ - If you'd like to submit a fix for a bug, please read the [How To](#how-to-contribute) for how to
+   send a Pull Request.
+ - Indicate on the open issue that you are working on fixing the bug and the issue will be assigned
+   to you.
+ - Write `Fixes #xxxx` in your PR text, where xxxx is the issue number (if there is one).
+ - Include a test that isolates the bug and verifies that it was fixed.
+
+### New Features
+ - If you'd like to add a feature to the library that doesn't already exist, feel free to describe
+   the feature in a new [GitHub issue].
+   - You can also join us on [Discord] to discuss some initials
+   thoughts.
+ - If you'd like to implement the new feature, please wait for feedback from the project maintainers
+   before spending too much time writing the code. In some cases, enhancements may not align well
+   with the project objectives at the time.
+ - Implement the code for the new feature and please read the [How To](#how-to-contribute).
+
+### Documentation & Miscellaneous
+ - If you have suggestions for improvements to the documentation, tutorial or examples (or something
+   else), we would love to hear about it.
+ - As always first file a [Github issue].
+ - Implement the changes to the documentation, please read the [How To](#how-to-contribute).
+
+## How To Contribute
+
+### Requirements
+For a contribution to be accepted:
+
+- Documentation should always be updated or added.*
+- Examples should always be updated or added.*
+- Tests should always be updated or added.*
+- Format the Dart code accordingly with `flutter format`.
+- Your code should pass the analyzer checks `melos run analyze`.
+- Your code should pass all tests `melos run test`.
+- Start your PR title with a [conventional commit] type
+  (`feat:`, `fix:` etc).
+
+*When applicable.
+
+If the contribution doesn't meet these criteria, a maintainer will discuss it with you on the issue
+or PR. You can still continue to add more commits to the branch you have sent the Pull Request from
+and it will be automatically reflected in the PR.
+
+## Open an issue and fork the repository
+ - If it is a bigger change or a new feature, first of all
+   [file a bug or feature report][GitHub issues], so that we can discuss what direction to follow.
+ - [Fork the project][fork guide] on GitHub.
+ - Clone the forked repository to your local development machine
+   (e.g. `git clone [email protected]:<YOUR_GITHUB_USER>/modular.git`).
+
+### Environment Setup
+Modular uses [Melos] to manage the project and dependencies.
+
+To install Melos, run the following command from your terminal:
+
+```bash
+flutter pub global activate melos
+```
+
+Next, at the root of your locally cloned repository bootstrap the projects dependencies:
+
+```bash
+melos bootstrap
+```
+
+The bootstrap command locally links all dependencies within the project without having to
+provide manual [`dependency_overrides`][pubspec doc]. This allows all
+plugins, examples and tests to build from the local clone project. You should only need to run this
+command once.
+
+> You do not need to run `flutter pub get` once bootstrap has been completed.
+
+### Performing changes
+ - Create a new local branch from `main` (e.g. `git checkout -b my-new-feature`)
+ - Make your changes.
+ - When committing your changes, make sure that each commit message is clear
+ (e.g. `git commit -m '[modular_interface] Added BindContract.onDispose.'`).
+ - Push your new branch to your own fork into the same remote branch
+ (e.g. `git push origin my-username.my-new-feature`, replace `origin` if you use another remote.)
+
+### Open a pull request
+Go to the [pull request page of modular][PRs] and in the top
+of the page it will ask you if you want to open a pull request from your newly created branch.
+
+The title of the pull request should start with a [conventional commit] type.
+
+Examples of such types:
+ - `fix:` - patches a bug and is not a new feature.
+ - `feat:` - introduces a new feature.
+ - `docs:` - updates or adds documentation or examples.
+ - `test:` - updates or adds tests.
+ - `refactor:` - refactors code but doesn't introduce any changes or additions to the public API.
+
+If you introduce a **breaking change** the conventional commit type MUST end with an exclamation
+mark (e.g. `feat!: The Bind.onDispose property for calls to destroy, close or dispose methods.`).
+
+Examples of PR titles:
+ - feat!: New auto-dispose configuration.
+ - feat: Added Modular.setArguments.
+ - docs: Add Contribution Guidelines.
+ - test: Add Export bind test.
+ - chore: Removed triple dependency.
+ - refactor: Now the main constructor of Bind is @Protected.
+
+[GitHub issue]: https://github.com/Flutterando/modular/issues/new
+[GitHub issues]: https://github.com/Flutterando/modular/issues/new
+[PRs]: https://github.com/Flutterando/modular/pulls
+[fork guide]: https://guides.github.com/activities/forking/#fork
+[Discord]: https://discord.gg/7qvSXRMMYw
+[Melos]: https://github.com/invertase/melos
+[pubspec doc]: https://dart.dev/tools/pub/pubspec
+[conventional commit]: https://www.conventionalcommits.org