Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: responseFile convert empty object to array #823

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 41 additions & 0 deletions CODE_REVIEW.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
# Code Review Guidelines

## Code Review Process

1. **Create a Pull Request**: When you have completed a feature or bug fix, create a pull request (PR) to the main branch.
2. **Assign Reviewers**: Assign at least one reviewer to your PR. Preferably, choose someone who is familiar with the codebase.
3. **Review the Code**: The assigned reviewer(s) will review the code, checking for functionality, readability, and adherence to coding standards.
4. **Address Feedback**: If the reviewer(s) request changes, address the feedback and update the PR.
5. **Approval and Merge**: Once the reviewer(s) approve the PR, it can be merged into the main branch.

## Best Practices

- **Write Clear and Concise Code**: Ensure your code is easy to read and understand.
- **Follow Coding Standards**: Adhere to the project's coding standards and guidelines.
- **Test Your Code**: Write unit tests for your code and ensure all tests pass before submitting a PR.
- **Keep PRs Small**: Submit small, focused PRs that are easier to review.
- **Provide Context**: Include a clear description of the changes in your PR and any relevant context.

## Common Issues

- **Lack of Tests**: Ensure your code is well-tested.
- **Poor Naming Conventions**: Use meaningful and descriptive names for variables, functions, and classes.
- **Inconsistent Formatting**: Follow the project's formatting guidelines.
- **Large PRs**: Break down large PRs into smaller, more manageable ones.
- **Lack of Documentation**: Document your code and provide comments where necessary.

## Examples of Good and Bad Code Reviews

### Good Code Review

- **Positive Feedback**: "Great job on this feature! The code is clean and well-organized."
- **Constructive Criticism**: "I noticed a potential issue with the error handling. Could you add a check for null values?"
- **Suggestions for Improvement**: "Consider using a more descriptive variable name here to improve readability."

### Bad Code Review

- **Negative Feedback**: "This code is terrible. You need to rewrite it."
- **Unclear Comments**: "Fix this."
- **Lack of Specificity**: "This needs improvement."

By following these guidelines, we can ensure a smooth and effective code review process that helps maintain the quality of our codebase.
12 changes: 12 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -47,3 +47,15 @@ Before submitting a pull request:
- **One pull request per feature** - If you want to do more than one thing, send multiple pull requests.

**Happy coding**!

## Code Review Guidelines

When submitting a pull request, please follow these code review guidelines:

1. **Create a Pull Request**: When you have completed a feature or bug fix, create a pull request (PR) to the main branch.
2. **Assign Reviewers**: Assign at least one reviewer to your PR. Preferably, choose someone who is familiar with the codebase.
3. **Review the Code**: The assigned reviewer(s) will review the code, checking for functionality, readability, and adherence to coding standards.
4. **Address Feedback**: If the reviewer(s) request changes, address the feedback and update the PR.
5. **Approval and Merge**: Once the reviewer(s) approve the PR, it can be merged into the main branch.

By following these guidelines, we can ensure a smooth and effective code review process that helps maintain the quality of our codebase.
3 changes: 3 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -46,6 +46,9 @@ $app->configure('apidoc');
## Documentation
Check out the documentation at the [Beyond Code homepage](https://beyondco.de/docs/laravel-apidoc-generator/).

## Code Review Process
We have a code review process in place to ensure the quality and consistency of our codebase. Please refer to the [Code Review Guidelines](CODE_REVIEW.md) for more information.

### License

The Laravel API Documentation Generator is free software licensed under the MIT license.
7 changes: 6 additions & 1 deletion src/Extracting/Strategies/Responses/UseResponseFileTag.php
Original file line number Diff line number Diff line change
Expand Up @@ -62,7 +62,12 @@ protected function getFileResponses(array $tags)
}
$status = $result[1] ?: 200;
$content = $result[2] ? file_get_contents($filePath, true) : '{}';
$json = ! empty($result[3]) ? str_replace("'", '"', $result[3]) : '{}';

if (empty($result[3])) {
return ['content' => $content, 'status' => (int) $status];
}

$json = str_replace("'", '"', $result[3]);
$merged = array_merge(json_decode($content, true), json_decode($json, true));

return ['content' => json_encode($merged), 'status' => (int) $status];
Expand Down