Skip to content

Commit 454d4fc

Browse files
committed
Add comprehensive documentation
- Add detailed README with examples and usage - Add CHANGELOG for version history - Add CONTRIBUTING guide for contributors - Document Nova 4 and 5 compatibility
1 parent bb7637f commit 454d4fc

3 files changed

Lines changed: 399 additions & 0 deletions

File tree

CHANGELOG.md

Lines changed: 19 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,19 @@
1+
# Changelog
2+
3+
All notable changes to `nova-dependency-container` will be documented in this file.
4+
5+
## [1.0.0] - 2024-12-26
6+
7+
### Added
8+
- Initial release
9+
- Support for Laravel Nova 5.x
10+
- Support for Laravel 11.x and 12.x
11+
- Support for PHP 8.3
12+
- Basic dependency methods: `dependsOn`, `dependsOnIn`, `dependsOnNot`, `dependsOnNotIn`
13+
- Advanced dependency methods: `dependsOnEmpty`, `dependsOnNotEmpty`, `dependsOnNullOrZero`
14+
- Ability to chain multiple dependencies
15+
- `HasDependencies` trait for adding dependencies to custom fields
16+
- `applyToFields()` method for flat structure dependencies
17+
- Comprehensive test suite with Pest
18+
- GitHub Actions for automated testing and code quality
19+
- Full documentation with examples

CONTRIBUTING.md

Lines changed: 71 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,71 @@
1+
# Contributing
2+
3+
Contributions are **welcome** and will be fully **credited**.
4+
5+
Please read and understand the contribution guide before creating an issue or pull request.
6+
7+
## Etiquette
8+
9+
This project is open source, and as such, the maintainers give their free time to build and maintain the source code held within. They make the code freely available in the hope that it will be of use to other developers. It would be extremely unfair for them to suffer abuse or anger for their hard work.
10+
11+
Please be considerate towards maintainers when raising issues or presenting pull requests. Let's show the world that developers are civilized and selfless people.
12+
13+
It's the duty of the maintainer to ensure that all submissions to the project are of sufficient quality to benefit the project. Many developers have different skillsets, strengths, and weaknesses. Respect the maintainer's decision, and do not be upset or abusive if your submission is not used.
14+
15+
## Viability
16+
17+
When requesting or submitting new features, first consider whether it might be useful to others. Open source projects are used by many developers, who may have entirely different needs to your own. Think about whether or not your feature is likely to be used by other users of the project.
18+
19+
## Procedure
20+
21+
Before filing an issue:
22+
23+
- Attempt to replicate the problem, to ensure that it wasn't a coincidental incident.
24+
- Check to make sure your feature suggestion isn't already present within the project.
25+
- Check the pull requests tab to ensure that the bug doesn't have a fix in progress.
26+
- Check the pull requests tab to ensure that the feature isn't already in progress.
27+
28+
Before submitting a pull request:
29+
30+
- Check the codebase to ensure that your feature doesn't already exist.
31+
- Check the pull requests to ensure that another person hasn't already submitted the feature or fix.
32+
33+
## Requirements
34+
35+
If the project maintainer has any additional requirements, you will find them listed here.
36+
37+
- **[PSR-12 Coding Standard](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-12-extended-coding-style-guide.md)** - The easiest way to apply the conventions is to run `composer format`.
38+
39+
- **Add tests!** - Your patch won't be accepted if it doesn't have tests.
40+
41+
- **Document any change in behaviour** - Make sure the `README.md` and any other relevant documentation are kept up-to-date.
42+
43+
- **Consider our release cycle** - We try to follow [SemVer v2.0.0](http://semver.org/). Randomly breaking public APIs is not an option.
44+
45+
- **One pull request per feature** - If you want to do more than one thing, send multiple pull requests.
46+
47+
- **Send coherent history** - Make sure each individual commit in your pull request is meaningful. If you had to make multiple intermediate commits while developing, please [squash them](http://www.git-scm.com/book/en/v2/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages) before submitting.
48+
49+
## Running Tests
50+
51+
```bash
52+
composer test
53+
```
54+
55+
## Code Style
56+
57+
Fix code style issues with:
58+
59+
```bash
60+
composer format
61+
```
62+
63+
## Static Analysis
64+
65+
Run PHPStan:
66+
67+
```bash
68+
composer analyse
69+
```
70+
71+
**Happy coding**!

0 commit comments

Comments
 (0)