feat: Use mdformat i/ of prettier

Author: Paillat-dev

.github/SECURITY.md

@@ -5,7 +5,7 @@
 | Version | Supported          |
 | ------- | ------------------ |
 | 2.x     | :white_check_mark: |
-| <2.6.1  | :x:                |
+| \<2.6.1 | :x:                |
 
 ## Reporting a Vulnerability
 

.github/workflows/lib-checks.yml

@@ -105,6 +105,20 @@ jobs:
           groups: "dev"
       - name: "Run bandit"
         run: bandit --recursive --exclude ./.venv --skip B101,B104,B105,B110,B307,B311,B404,B603,B607 .
+  mdformat:
+    needs: [ changes ]
+    if: ${{ needs.changes.outputs.lib == 'true' && github.event_name != 'schedule' }}
+    runs-on: ubuntu-latest
+    steps:
+      - name: "Checkout Repository"
+        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
+      - name: "Setup uv"
+        uses: ./.github/actions/setup-uv
+        with:
+          python-version: "3.14"
+          groups: "dev"
+      - name: "Run mdformat"
+        run: git ls-files -z '*.md' | xargs -0 -r mdformat --check
   pylint:
     needs: [ changes ]
     if: ${{ needs.changes.outputs.lib == 'true' && github.event_name != 'schedule' }}

.mdformat.toml

@@ -0,0 +1,2 @@
+wrap = 100
+number = true

.pre-commit-config.yaml

@@ -81,12 +81,13 @@ repos:
   #    hooks:
   #      - id: mypy
 
-  - repo: https://github.com/pre-commit/mirrors-prettier
-    rev: v4.0.0-alpha.8
+  - repo: https://github.com/hukkin/mdformat
+    rev: 1.0.0
     hooks:
-      - id: prettier
-        args: [--prose-wrap=always, --print-width=88]
-        exclude: \.(po|pot|yml|yaml)$
+      - id: mdformat
+        additional_dependencies:
+          - mdformat-gfm==1.0.0
+          - mdformat-gfm-alerts==2.1.0
   - repo: https://github.com/DanielNoord/pydocstringformatter
     rev: v1.0.0
     hooks:

.prettierrc

@@ -1,10 +1,9 @@
 ## Contributing to Pycord
 
-First off, thanks for taking the time to contribute. It makes the library substantially
-better. :+1:
+First off, thanks for taking the time to contribute. It makes the library substantially better. :+1:
 
-The following is a set of guidelines for contributing to the repository. These are
-guidelines, not hard rules.
+The following is a set of guidelines for contributing to the repository. These are guidelines, not
+hard rules.
 
 ## This is too much to read! I want to ask a question!
 
@@ -14,106 +13,102 @@ Generally speaking questions are better suited in our resources below.
 - [The FAQ in the documentation](https://docs.pycord.dev/en/master/faq.html)
 - [StackOverflow's `pycord` tag](https://stackoverflow.com/questions/tagged/pycord)
 
-Please try your best not to ask questions in our issue tracker. Most of them don't
-belong there unless they provide value to a larger audience.
+Please try your best not to ask questions in our issue tracker. Most of them don't belong there
+unless they provide value to a larger audience.
 
 ## Good Bug Reports
 
 Please be aware of the following things when filing bug reports.
 
-1. Don't open duplicate issues. Please search your issue to see if it has been asked
-   already. Duplicate issues will be closed.
-2. When filing a bug about exceptions or tracebacks, please include the _complete_
-   traceback. Without the complete traceback the issue might be **unsolvable** and you
-   will be asked to provide more information.
-3. Make sure to provide enough information to make the issue workable. The issue
-   template will generally walk you through the process but they are enumerated here as
-   well:
-   - A **summary** of your bug report. This is generally a quick sentence or two to
-     describe the issue in human terms.
-   - Guidance on **how to reproduce the issue**. Ideally, this should have a small code
-     sample that allows us to run and see the issue for ourselves to debug. **Please
-     make sure that the token is not displayed**. If you cannot provide a code snippet,
-     then let us know what the steps were, how often it happens, etc.
+1. Don't open duplicate issues. Please search your issue to see if it has been asked already.
+   Duplicate issues will be closed.
+2. When filing a bug about exceptions or tracebacks, please include the _complete_ traceback.
+   Without the complete traceback the issue might be **unsolvable** and you will be asked to provide
+   more information.
+3. Make sure to provide enough information to make the issue workable. The issue template will
+   generally walk you through the process but they are enumerated here as well:
+   - A **summary** of your bug report. This is generally a quick sentence or two to describe the
+     issue in human terms.
+   - Guidance on **how to reproduce the issue**. Ideally, this should have a small code sample that
+     allows us to run and see the issue for ourselves to debug. **Please make sure that the token is
+     not displayed**. If you cannot provide a code snippet, then let us know what the steps were,
+     how often it happens, etc.
    - Tell us **what you expected to happen**. That way we can meet that expectation.
-   - Tell us **what actually happens**. What ends up happening in reality? It's not
-     helpful to say "it fails" or "it doesn't work". Say _how_ it failed, do you get an
-     exception? Does it hang? How are the expectations different from reality?
-   - Tell us **information about your environment**. What version of Pycord are you
-     using? How was it installed? What operating system are you running on? These are
-     valuable questions and information that we use.
+   - Tell us **what actually happens**. What ends up happening in reality? It's not helpful to say
+     "it fails" or "it doesn't work". Say _how_ it failed, do you get an exception? Does it hang?
+     How are the expectations different from reality?
+   - Tell us **information about your environment**. What version of Pycord are you using? How was
+     it installed? What operating system are you running on? These are valuable questions and
+     information that we use.
 
-If the bug report is missing this information then it'll take us longer to fix the
-issue. We will probably ask for clarification, and barring that if no response was given
-then the issue will be closed.
+If the bug report is missing this information then it'll take us longer to fix the issue. We will
+probably ask for clarification, and barring that if no response was given then the issue will be
+closed.
 
 ## Submitting a Pull Request
 
-Submitting a pull request is fairly simple, just make sure it focuses on a single aspect
-and doesn't manage to have scope creep and it's probably good to go. It would be
-incredibly lovely if the style is consistent to that found in the project. This project
-follows PEP-8 guidelines (mostly) with a column limit of 120.
+Submitting a pull request is fairly simple, just make sure it focuses on a single aspect and doesn't
+manage to have scope creep and it's probably good to go. It would be incredibly lovely if the style
+is consistent to that found in the project. This project follows PEP-8 guidelines (mostly) with a
+column limit of 120.
 
 ## Use of "type: ignore" comments
 
-In some cases, it might be necessary to ignore type checker warnings for one reason or
-another. If that is the case, it is **required** that a comment is left explaining why
-you are deciding to ignore type checking warnings.
+In some cases, it might be necessary to ignore type checker warnings for one reason or another. If
+that is the case, it is **required** that a comment is left explaining why you are deciding to
+ignore type checking warnings.
 
 ## Licensing
 
 By submitting a pull request, you agree to and accept the following:
 
 1. You hold the copyright on all submitted code inside said pull request.
 2. You transfer all rights to the owner of this repository.
-3. If you are found to be in fault with any of the above, we shall not be held
-   responsible in any way after the pull request has been merged.
+3. If you are found to be in fault with any of the above, we shall not be held responsible in any
+   way after the pull request has been merged.
 
 ## Git Commit Styling
 
-Not following this guideline could lead to your pull being squashed for a cleaner commit
-history
+Not following this guideline could lead to your pull being squashed for a cleaner commit history
 
 Some style guides we would recommend using in your pulls:
 
-The [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/) style is a
-very widely used style and a good style to start with.
+The [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/) style is a very widely
+used style and a good style to start with.
 
-The [gitmoji](https://gitmoji.dev) style guide would make your pull look more lively and
-different to others.
+The [gitmoji](https://gitmoji.dev) style guide would make your pull look more lively and different
+to others.
 
-We don't limit nor deny your pulls when you're using another style although, please make
-sure it is appropriate and makes sense in this library.
+We don't limit nor deny your pulls when you're using another style although, please make sure it is
+appropriate and makes sense in this library.
 
 ## AI Usage Policy
 
-The use of LLMs or other AI tools must be disclosed at all times. Disclosure is required
-for any interaction or contribution including, but not limited to, the following:
+The use of LLMs or other AI tools must be disclosed at all times. Disclosure is required for any
+interaction or contribution including, but not limited to, the following:
 
 - Modifying code
 - Modifying documentation
 - Discussion with maintainers
 - Issue bodies and comments
 - Pull request bodies and comments
 
-The disclosure must specify the tools used and the scope of their application. The
-primary location of disclosure should be in the body of issues and pull requests.
+The disclosure must specify the tools used and the scope of their application. The primary location
+of disclosure should be in the body of issues and pull requests.
 
 If you are not a native English speaker, using LLMs or other AI tools for translation is
-discouraged. It can distort your intended meaning and make a human-written contribution
-look AI-generated. Please use a non-LLM-based translation tool such as
-[DeepL](https://deepl.com) instead.
+discouraged. It can distort your intended meaning and make a human-written contribution look
+AI-generated. Please use a non-LLM-based translation tool such as [DeepL](https://deepl.com)
+instead.
 
-The use of fully autonomous LLMs or other AI tools to open issues or pull requests is
-strictly forbidden.
+The use of fully autonomous LLMs or other AI tools to open issues or pull requests is strictly
+forbidden.
 
-Failure to follow this policy may result in a temporary or permanent ban from our
-organization.
+Failure to follow this policy may result in a temporary or permanent ban from our organization.
 
-The use of LLMs or AI tools by new contributors is highly discouraged, and will likely
-result in the direct closure of your issue or pull request.
+The use of LLMs or AI tools by new contributors is highly discouraged, and will likely result in the
+direct closure of your issue or pull request.
 
-Furthermore, as outlined earlier in §"Licensing," by submitting a pull request, you
-agree that you hold the copyright on your contribution, and that you understand how your
-submitted code works and are able to explain its purpose, behavior, and impact when
-requested.
+Furthermore, as outlined earlier in §"Licensing," by submitting a pull request, you agree that you
+hold the copyright on your contribution, and that you understand how your submitted code works and
+are able to explain its purpose, behavior, and impact when requested.