chore: update pre-commit hooks (#449)

* chore: update pre-commit hooks

updates:
- [github.com/adamchainz/blacken-docs: 1.16.0 → 1.18.0](adamchainz/blacken-docs@1.16.0...1.18.0)
- [github.com/pre-commit/mirrors-prettier: v3.1.0 → v4.0.0-alpha.8](pre-commit/mirrors-prettier@v3.1.0...v4.0.0-alpha.8)

* style: pre-commit fixes

---------

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

.pre-commit-config.yaml

@@ -23,7 +23,7 @@ repos:
       - id: trailing-whitespace
 
   - repo: https://github.com/adamchainz/blacken-docs
-    rev: "1.16.0"
+    rev: "1.18.0"
     hooks:
       - id: blacken-docs
         additional_dependencies: [black==24.*]
@@ -58,7 +58,7 @@ repos:
           - types-PyYAML
 
   - repo: https://github.com/pre-commit/mirrors-prettier
-    rev: "v3.1.0"
+    rev: "v4.0.0-alpha.8"
     hooks:
       - id: prettier
         types_or: [yaml, markdown, html, css, scss, javascript, json]

README.md

@@ -39,10 +39,10 @@ During generation you can select from the following backends for your package:
 1. [hatch][]: This uses hatchling, a modern builder with nice file inclusion,
    extendable via plugins, and good error messages. **(Recommended for pure
    Python projects)**
-2. [flit][]: A modern, lightweight [PEP 621][] build system for pure Python
-   projects. Replaces setuptools, no MANIFEST.in, setup.py, or setup.cfg. Low
-   learning curve. Easy to bootstrap into new distributions. Difficult to get
-   the right files included, little dynamic metadata support.
+2. [flit][]: A modern, lightweight [PEP 621][] build system for pure Python projects.
+   Replaces setuptools, no MANIFEST.in, setup.py, or setup.cfg. Low learning curve.
+   Easy to bootstrap into new distributions. Difficult to get the right files included,
+   little dynamic metadata support.
 3. [pdm][]: A modern, less opinionated all-in-one solution to pure Python
    projects supporting standards. Replaces setuptools, venv/pipenv, pip, wheel,
    and twine. Supports [PEP 621][].
@@ -61,8 +61,8 @@ During generation you can select from the following backends for your package:
 9. [scikit-build][]: A scikit-build (CMake) project also using pybind11, using
    scikit-build-core. **(Recommended for C++ projects)**
 10. [meson-python][]: A Meson project also using pybind11. (No VCS versioning)
-11. [maturin][]: A [PEP 621][] builder for Rust binary extensions. (No VCS
-    versioning) **(Recommended for Rust projects)**
+11. [maturin][]: A [PEP 621][] builder for Rust binary extensions. (No VCS versioning)
+    **(Recommended for Rust projects)**
 
 Currently, the best choice is probably hatch for pure Python projects, and
 scikit-build (such as the scikit-build-core + pybind11 choice) for binary
@@ -238,8 +238,8 @@ A lot of the guide, cookiecutter, and repo-review started out as part of
 
 <!-- sp-repo-review -->
 
-`sp-repo-review` provides checks based on the [Scientific-Python Development
-Guide][] at [scientific-python/cookie][] for [repo-review][].
+`sp-repo-review` provides checks based on the [Scientific-Python
+Development Guide][] at [scientific-python/cookie][] for [repo-review][].
 
 This tool can check the style of a repository. Use like this:
 

docs/pages/guides/gha_pure.md

@@ -11,11 +11,11 @@ custom_title: GitHub Actions for pure Python wheels
 
 # GitHub Actions: Pure Python wheels
 
-We will cover binary wheels [on the next page][], but if you do not have a
-compiled extension, this is called a universal (pure Python) package, and the
-procedure to make a "built" wheel is simple. At the end of this page, there is a
-recipe that can often be used exactly for pure Python wheels (if the previous
-recommendations were followed).
+We will cover binary wheels [on the next page][], but if you do not have a compiled
+extension, this is called a universal (pure Python) package, and the procedure to
+make a "built" wheel is simple. At the end of this page, there is a recipe that can
+often be used exactly for pure Python wheels (if the previous recommendations were
+followed).
 
 {: .note }
 
@@ -89,8 +89,8 @@ dist:
 {% endraw %}
 
 We use [PyPA-Build](https://pypa-build.readthedocs.io/en/latest/), a new build
-tool designed to make building wheels and SDists easy. It run a [PEP 517][]
-backend and can get [PEP 518][] requirements even for making SDists.
+tool designed to make building wheels and SDists easy. It run a [PEP 517][] backend
+and can get [PEP 518][] requirements even for making SDists.
 
 By default this will make an SDist and a wheel from the package in the current
 directory, and they will be placed in `./dist`. You can only build SDist (`-s`),
@@ -166,8 +166,8 @@ publish:
 When you make a GitHub release in the web UI, we publish to PyPI. You'll just
 need to tell PyPI which org, repo, workflow, and set the `pypi` environment to
 allow pushes from GitHub. If it's the first time you've published a package, go
-to the [PyPI trusted publisher docs] for instructions on preparing PyPI to
-accept your initial package publish.
+to the [PyPI trusted publisher docs] for instructions on preparing PyPI to accept
+your initial package publish.
 
 We are also generating artifact attestations, which can allow users to verify
 that the artifacts were built on your actions.

docs/pages/guides/gha_wheels.md

@@ -190,8 +190,8 @@ upload_all:
 When you make a GitHub release in the web UI, we publish to PyPI. You'll just
 need to tell PyPI which org, repo, workflow, and set the `pypi` environment to
 allow pushes from GitHub. If it's the first time you've published a package, go
-to the [PyPI trusted publisher docs] for instructions on preparing PyPI to
-accept your initial package publish.
+to the [PyPI trusted publisher docs] for instructions on preparing PyPI to accept
+your initial package publish.
 
 We are also generating artifact attestations, which can allow users to verify
 that the artifacts were built on your actions.

docs/pages/guides/index.md

@@ -18,9 +18,9 @@ for your `CONTRIBUTING.md`, and at least glance through other sections.
 Following that, there are recommendations for [style][], intended to promote
 good practices and to ensure continuity across the packages. There is a
 [dedicated page for static type checking with MyPy][mypy]. There is then a guide
-on [simple packaging][], [compiled packaging][], or even [classic packaging][],
-which should help in ensuring a consistent developer and user experience when
-working with distribution.
+on [simple packaging][], [compiled packaging][], or even [classic packaging][], which
+should help in ensuring a consistent developer and user experience when working with
+distribution.
 
 A section on CI follows, with a [general setup guide][gha_basic], and then two
 choices for using CI to distribute your package, on for [pure Python][gha_pure],
@@ -43,8 +43,8 @@ on setting up [docs][], as well.
 > Checking an existing project
 >
 > We provide [sp-repo-review][], a set of [repo-review][] checks for comparing
-> your repository with the guidelines, runnable [right in the guide][] via
-> WebAssembly! All checks point to a linked badge in the guide.
+> your repository with the guidelines, runnable [right in the guide][] via WebAssembly!
+> All checks point to a linked badge in the guide.
 
 <!-- prettier-ignore-start -->
 

docs/pages/guides/mypy.md

@@ -77,8 +77,7 @@ to a code base. By default:
 You can add configuration to `pyproject.toml` (and a little bit to the files
 themselves), or you can go all the way and pass `--strict`, which will turn on
 everything. Try to turn on as much as possible, and increase it until you can
-run with full `strict` checking. See the [style page][] for configuration
-suggestions.
+run with full `strict` checking. See the [style page][] for configuration suggestions.
 
 [style page]: {% link pages/guides/style.md %}
 

docs/pages/guides/packaging_classic.md

@@ -22,8 +22,8 @@ like [Hatch][] are drastically simpler - most of this page is unneeded for those
 systems. Even setuptools supports modern config now, though setup.py is still
 also required for compiled packages to be supported.
 
-Also see the [Python packaging guide][], especially the [Python packaging
-tutorial][].
+Also see the [Python packaging guide][], especially the [Python
+packaging tutorial][].
 
 {: .note }
 

docs/pages/guides/packaging_compiled.md

@@ -26,8 +26,8 @@ The most exciting developments have been new native build backends:
 
 {: .note }
 
-You should be familiar with [packing a pure Python
-project]({% link pages/guides/packaging_compiled.md %}) - the metadata
+You should be familiar with [packing a pure
+Python project]({% link pages/guides/packaging_compiled.md %}) - the metadata
 configuration is the same.
 
 There are also classic setuptools plugins:

docs/pages/guides/packaging_simple.md

@@ -13,11 +13,11 @@ parent: Topical Guides
 Python packages can now use a modern build system instead of the classic but
 verbose setuptools and `setup.py`. The one you select doesn't really matter that
 much; they all use a [standard configuration language][metadata] introduced in
-[PEP 621][]. The PyPA's Flit is a great option. [scikit-build-core][] and
-[meson-python][] are being developed to support this sort of configuration,
-enabling binary extension packages to benefit too. These [PEP 621][] tools
-currently include [Hatch][], [PDM][], [Flit][], [Whey][], and [Setuptools][].
-[Poetry][] will eventually gain support in 2.0.
+[PEP 621][]. The PyPA's Flit is a great option. [scikit-build-core][] and [meson-python][]
+are being developed to support this sort of configuration, enabling binary extension
+packages to benefit too. These [PEP 621][] tools currently include [Hatch][],
+[PDM][], [Flit][], [Whey][], and [Setuptools][]. [Poetry][] will eventually gain
+support in 2.0.
 
 {: .note-title }
 

docs/pages/index.md

@@ -19,8 +19,8 @@ maintainable, reusable, and shareable form? Start at the
 **Learn recommended tools and best practices.** [Topical guides]({% link
 pages/guides/index.md %}) provide task-based instruction on topics that scientists
 and research software engineers may encounter as their projects evolve and grow.
-This covers modern packaging ([simple][] or [compiled][]), [style checking][], [testing][],
-[documentation][], [static typing][], [CI][], and much more!
+This covers modern packaging ([simple][] or [compiled][]), [style checking][],
+[testing][], [documentation][], [static typing][], [CI][], and much more!
 
 {: .highlight-title }
 
@@ -36,8 +36,8 @@ This covers modern packaging ([simple][] or [compiled][]), [style checking][], [
 > Checking an existing project
 >
 > We provide [sp-repo-review][], a set of [repo-review][] checks for comparing
-> your repository with the guidelines, runnable [right in the guide][] via
-> WebAssembly! All checks point to a linked badge in the guide.
+> your repository with the guidelines, runnable [right in the guide][] via WebAssembly!
+> All checks point to a linked badge in the guide.
 
 **Learn to write better research code.** A high-level document on
 [principles]({% link pages/principles/index.md %}) provides advice based on the

docs/pages/principles/design.md

@@ -24,9 +24,9 @@ test, maintain when data formats change, or reuse for unforeseen applications.
 
 ## Duck typing is a good idea
 
-[Duck typing][] treats objects based on what they can _do_, not based on what
-type they _are_. "If it walks like a duck and it quacks like a duck, then it
-must be a duck."
+[Duck typing][] treats objects based on what they can _do_, not based on what type
+they _are_. "If it walks like a duck and it quacks like a duck, then it must be a
+duck."
 
 Python in general and scientific Python in particular leverage _interfaces_
 (also known as Protocols) to support interoperability and reuse. For example, it

docs/pages/principles/index.md

@@ -9,9 +9,9 @@ has_children: true
 # Principles
 
 These pages are focused on designing good software, with a focus on end-user
-research code. [Process recommendations][] discusses the process of writing
-software, and [Design recommendations][] covers some tips about writing easy to
-read and maintain code.
+research code. [Process recommendations][] discusses the process of writing software,
+and [Design recommendations][] covers some tips about writing easy to read and
+maintain code.
 
 <!-- prettier-ignore-start -->
 

docs/pages/tutorials/module.md

@@ -18,9 +18,9 @@ In this section you will:
 ## Module
 
 As a concrete example, let's suppose we have a simple function that encodes
-[Snell's Law][]. Perhaps this function currently lives in a Jupyter notebook or
-a `.py` file in an email attachment. We want to put into some more lasting,
-maintainable, reusable, and/or shareable form.
+[Snell's Law][]. Perhaps this function currently lives in a Jupyter notebook or a
+`.py` file in an email attachment. We want to put into some more lasting, maintainable,
+reusable, and/or shareable form.
 
 Here is the code:
 
@@ -64,8 +64,8 @@ is extremely useful for collaborators, and the most common collaborator is
 Future You! It also includes type hints; this tells a programmer, type checker,
 or IDE what types are expected in an out of the function.
 
-Further, by following the [numpydoc standard][], we will be able to
-automatically generate nice-looking HTML documentation later. Notable features:
+Further, by following the [numpydoc standard][], we will be able to automatically
+generate nice-looking HTML documentation later. Notable features:
 
 - At the top, there is a succinct, one-line summary of the function's purpose.
   It must one line.

docs/pages/tutorials/packaging.md

@@ -32,9 +32,9 @@ cd example
 
 You should immediately initialize an empty Git repository in this directory; if
 you need a refresher on using Git for version control, check out the Software
-Carpentry lesson [Version Control with Git][]. You should commit changes
-regularly throughout what follows. This tutorial will not explicitly remind you
-to commit your work after this point.
+Carpentry lesson [Version Control with Git][]. You should commit changes regularly
+throughout what follows. This tutorial will not explicitly remind you to commit your
+work after this point.
 
 ```bash
 git init

docs/pages/tutorials/test.md

@@ -146,8 +146,8 @@ include:
 - `-k EXPRESSION` Filter tests by pattern-matching test name.
 - `--lf` Run only tests that failed on the previous run (**l**ast **f**ail).
 
-Consult the [pytest documentation][] for more. For more advanced pytest
-suggestions, see our [pytest guide][].
+Consult the [pytest documentation][] for more. For more advanced pytest suggestions,
+see our [pytest guide][].
 
 <!-- prettier-ignore-start -->