This project and everyone participating in it is governed by the Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to esthersoftwaredev.

Do not open issues for general support questions as we want to keep GitHub issues for bug reports and feature requests. Instead, we recommend using Discussions or Discord to ask support-related questions.

Not all issues are bug fixes! Please understand the difference between a Feature and a Bug when it comes to issue creation.

• FEATURE - when you are implementing something new that has not been worked on before
• BUG - when you are correcting something that has been worked on before

Example:

• Responsiveness - when you start working on responsiveness, if no one has done anything related to responsiveness throughout a view or the entire app, then you are working on a feature and not a bug.

This process allows us to better coordinate our efforts, prevent duplication of work, and help you to craft the change so that it is successfully accepted into the project.

Before opening an issue, please check to see if a similar issue has been raised. Existing discussions may provide useful insights or workarounds.

Evaluate whether the Issue is a Feature or a Bug and submit the correct issue type. You can file new issues by selecting from our new issue templates and filling out the issue template.

To expedite bug fixes, a minimal reproduction of the issue is required. This concise example helps in swiftly identifying and addressing the problem.

Providing a minimal reproduction is crucial for saving time, increasing the chances of a quick resolution, and ensuring that focus is given to the correct issue.

DO NOT erase the provided issue template! It is intended for you to use, not to replace it with random text.

It is always a good practice to look up existing issues and ensure your new issue matches the established format. This helps maintain consistency and makes it easier for others to understand and collaborate on the issue.

Every new issue is tagged with the "needs triage" label, signifying that it requires review and assessment by a core team member. This process ensures that issues are appropriately prioritized and assigned, fostering a collaborative environment where tasks are synchronized to prevent conflicts. While you focus on addressing an issue, it's important to recognize that others may be working on related tasks. Therefore, the "needs triage" label serves as a precautionary measure, indicating that the issue is not yet ready for immediate attention. The issue will be ready to work on, once the "needs triage" label is removed.

All app versions maintain consistent file structures, functionalities, and feature implementations deliberately. The variations between versions are minimal, primarily revolving around the utilization of UI components where a UI library is used.

Once an issue has been resolved in one app version, the same implementation must be extended to all other versions, unless a superior alternative is proposed and accepted.

Any new implementation suggestion must be discussed to verify it's suitable for adoption across all app versions.

Before commencing work on any issue, it is essential to confirm that it has not already been addressed. Please check for existing implementations and their corresponding app versions. If the chosen issue has already been resolved in a different app version, review the existing implementation and replicate it accordingly.

Even if the issue is labeled as not implemented, it remains your responsibility to examine the app's codebase and confirm the absence of the issue.

Before you submit your Pull Request (PR) consider the following guidelines:

1. Search Hashnode with Angular for an open or closed PR that relates to your submission. You don't want to duplicate existing efforts.
2. Be sure that an issue describes the problem you're fixing, or documents the design for the feature you'd like to add. Discussing the design upfront helps to ensure that we're ready to accept your work.
3. Fork the Hashnode with Angular repo of your choice.
4. In your forked repository, make your changes in a new git branch:

   git checkout -b my-fix-branch main

5. Create your patch, including appropriate test cases.
6. Follow the Coding Standards
7. Run the full test suite, as described in the developer documentation, and ensure that all tests pass.
8. Commit your changes using a descriptive commit message following the Commit Message Guidelines

   git commit --all

   Note: the optional commit --all command line option will automatically "add" and "rm" edited files.

9. Push your branch to GitHub:

   git push origin my-fix-branch

10. In GitHub, send a pull request to HashnodeWithAngular/angular:main

DO NOT erase the provided PR template! It is intended for you to use, not to replace it with random text.

It is always a good practice to look up already merged PRs and ensure your new PR matches the established format. This helps maintain consistency and makes it easier for others to understand and collaborate.

I reserve the right not to accept pull requests from community members who haven't been good citizens of the community.

After your pull request is merged

1. Delete the remote branch on GitHub either through the GitHub web UI or your local shell as follows:

   git push origin --delete my-fix-branch

2. Check out the main branch:

   git checkout main -f

3. Delete the local branch:

   git branch -D my-fix-branch

4. Update your local main with the latest upstream version:

   git pull --ff upstream main

Components

Store full components that can be used on their own, in the components folder, examples include:

• header, footer, posts, series, post-details, layout, sidenav

Partial Components

Place partial components like dialogs and other smaller reusable components, in the partials folder, examples:

• settings-dialog, follow-dialog, search-dialog, svg-icon

Interfaces

Keep interfaces in the models folder, examples:

• blog-info.ts, post.ts

• Avoid duplicating existing interfaces or importing them in the wrong file.

Services

Place services in the services folder, examples:

• blog.service.ts, theme.service.ts

Custom - Pipes, Directives

Custom pipes to be placed in the pipes folder

Custom directives to be placed in the directives folder

Naming Conventions

• For dialogs, ensure the inclusion of the term dialog in the name.
• Maintain consistency with established naming conventions in other app versions.
• Propose suggestions for improved and clearer naming in discussions or comments.

Style Guide

The project utilizes SCSS. Copying and pasting CSS from other sources would be accepted only if it is formatted correctly to comply with SCSS conventions.

use relative measurements in the scss files:

• rem, %
• wh, vh, dvw dvh
• avoid using px

Media queries

The placement for media queries is the standard placement - below all the other styles.

Indentation & Formatting

Maintain the project's indentation and formatting. Do not include formatting changes in your PRs, only include code that you have changed. It doesn't look like you have done more when you submit a PR with tons of indentation changes - we all see its just indentation and that makes it even more unpleasant to deal with.

To maintain a clear and organized version history, we follow a standardized commit message convention. This ensures that each commit provides valuable information about the changes made. Please adhere to the following guidelines when crafting your commit messages:

Feature:

feat(component): add new feature X

Bug Fix:

fix(component): resolve issue with Y

Documentation Update:

docs(readme): update installation instructions

Code Refactor:

refactor(service): restructure data fetching logic

Performance Improvements:

perf(api): optimize data retrieval for faster response

Test:

test(component): add unit tests for feature Z

Chore (Release):

chore: prepare for version 1.0.0 release

Revert

revert: revert changes from commit abc123

Kindly ensure that all Pull Requests strictly adhere to our Coding Standards and Commit Message Guidelines. Non-compliant PRs must be adjusted prior to acceptance.

Reviewer Accountability

Reviewers who approve PRs not in alignment with the Coding Standards and Commit Message Guidelines may face restrictions on their approval privileges.