🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

Before submitting a pull request, you should run the following tests to ensure your changes don’t break anything:

1. Unit Tests: Run the unit tests for your changes to make sure the individual functions or components behave as expected.
2. Integration Tests: Verify that your changes work well with other parts of the codebase and ensure the different components integrate correctly.
3. Linting/Code Style Checks: Make sure your code adheres to the project's style guidelines (e.g., using ESLint, Prettier) to ensure consistency.
4. Build Tests: Ensure that the code compiles and that the application can be built without errors.
5. Regression Tests: Run tests to make sure that your changes haven’t unintentionally broken existing functionality.
6. Manual Testing (if applicable): For UI/UX changes or complex features, manually test the functionality in the local development environment to ensure everything behaves as expected.

Running these tests before submitting a pull request helps maintain the integrity of the codebase and speeds up the review process.

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

Before submitting a pull request, you should run the full unit test suite and add tests for any new or changed logic. Integration or end-to-end tests should be run if the change affects multiple components or user flows. It’s also important to run linters, type checks, and ensure the project builds successfully. For bug fixes, add a regression test to prevent the issue from reoccurring, and do a quick manual sanity check where applicable.

Before you hit “Create Pull Request,” it’s a good idea to double check a few things to make sure your changes are solid:

• Run the tests: Make sure all the relevant tests pass unit tests, integration tests, and any end-to-end tests if your project has them.
• Lint and format: Clean, consistent code is easier to review and maintain. Run your linter and formatter to catch any style issues.
• Security check: If you’ve added new dependencies or touched sensitive parts of the code, run a quick security scan to catch any vulnerabilities.
• Manual testing: If your changes affect the UI or involve tricky logic, give it a quick manual test to make sure everything behaves as expected.
• Review your PR: Read through your changes one last time. Make sure your PR description clearly explains what you did and why it helps reviewers a lot.

Before opening a PR, I usually do a quick sanity check:

• Run all existing tests and make sure they pass
• Manually test what I changed and nearby features
• Check for obvious regressions in common flows
• Run linting and make sure there are no warnings
• Do a full build to catch compile or type errors
  If all that looks good, I’m confident the PR won’t break anything and reviewers can focus on the code itself.