chore: More linting

@nicholasdower is smarter than me. What's missing was the
`listItemIndent` setting

markdown/dev/guides/best-practices/use-percentages/en.md

@@ -19,8 +19,8 @@ Instead, embrace percentages as options.
 To check how well your pattern scales, you can
 use the _antperson_ test by sampling the pattern for 2 models:
 
--   A model with measurements of avarage person (the person)
--   A model with measurements 1/10th of an average person (the ant)
+- A model with measurements of avarage person (the person)
+- A model with measurements 1/10th of an average person (the ant)
 
 A well-designed pattern will scale a factor 10 down and hold its shape.
 If your pattern makes assumptions about size, this test will show that.

markdown/dev/guides/code-of-conduct/enforcement/en.md

@@ -6,8 +6,8 @@ order: 50
 Instances of abusive, harassing, or otherwise unacceptable behavior
 may be reported to the community leaders responsible for enforcement:
 
--   Joost De Cock (joost@joost.at)
--   Sorcha Ní Dhubhghaill (nidhubhs@gmail.com)
+- Joost De Cock (joost@joost.at)
+- Sorcha Ní Dhubhghaill (nidhubhs@gmail.com)
 
 All complaints will be reviewed and investigated promptly and fairly.
 

markdown/dev/guides/code-of-conduct/our-standards/en.md

@@ -5,16 +5,16 @@ order: 20
 
 Examples of behavior that contributes to a positive environment for our community include:
 
--   Demonstrating empathy and kindness toward other people
--   Being respectful of differing opinions, viewpoints, and experiences
--   Giving and gracefully accepting constructive feedback
--   Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
--   Focusing on what is best not just for us as individuals, but for the overall community
+- Demonstrating empathy and kindness toward other people
+- Being respectful of differing opinions, viewpoints, and experiences
+- Giving and gracefully accepting constructive feedback
+- Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
+- Focusing on what is best not just for us as individuals, but for the overall community
 
 Examples of unacceptable behavior include:
 
--   The use of sexualized language or imagery, and sexual attention or advances of any kind
--   Trolling, insulting or derogatory comments, and personal or political attacks
--   Public or private harassment
--   Publishing others’ private information, such as a physical or email address, without their explicit permission
--   Other conduct which could reasonably be considered inappropriate in a professional setting
+- The use of sexualized language or imagery, and sexual attention or advances of any kind
+- Trolling, insulting or derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others’ private information, such as a physical or email address, without their explicit permission
+- Other conduct which could reasonably be considered inappropriate in a professional setting

markdown/dev/guides/docs/en.md

@@ -10,10 +10,10 @@ documentation can help you find your feet, and figure out what goes where.
 
 Our documentation is divided into four different types:
 
--   [**Tutorials**](/tutorials) are lessons that lead you through a series of steps to complete a project.
--   [**Guides**](/guides) tell a story to further your understanding of a specific topic.
--   [**Howtos**](/howtos) give you concrete steps to solve a common problem or challenge.
--   [**Reference**](/reference) holds technical descriptions of the underlying technology and how to make use of it.
+- [**Tutorials**](/tutorials) are lessons that lead you through a series of steps to complete a project.
+- [**Guides**](/guides) tell a story to further your understanding of a specific topic.
+- [**Howtos**](/howtos) give you concrete steps to solve a common problem or challenge.
+- [**Reference**](/reference) holds technical descriptions of the underlying technology and how to make use of it.
 
 Each time you write documentation, you have to ask yourself: Is it a tutorial? Is it a Guide?
 Is it a Howto? Or is it Reference documentation.
@@ -24,11 +24,11 @@ where your documentation should go based on what it's trying to accomplish:
 ![A graphic showing a visual representation of our documentation
 structure](docs.png "A visual representation of how our documentation is structured")
 
--   Write a **Tutorial** is your aim is to help people learn the platform
--   Write a **Guide** if your aim is to further people's understanding of a topic by going a bit deeper
--   Write a **Howto** if your ain is to help people accomplish a task
--   Write **Reference** documentation to detail how things work under the hood
--   Refer people to **Discord or Github** for things that are not (yet) covered in our documentation
+- Write a **Tutorial** is your aim is to help people learn the platform
+- Write a **Guide** if your aim is to further people's understanding of a topic by going a bit deeper
+- Write a **Howto** if your ain is to help people accomplish a task
+- Write **Reference** documentation to detail how things work under the hood
+- Refer people to **Discord or Github** for things that are not (yet) covered in our documentation
 
 <Note>
 

markdown/dev/guides/markdown/code-blocks/en.md

@@ -38,11 +38,11 @@ let me = 'you'
 
 The following language codes are supported:
 
--   `js` for Javascript code
--   `markdown` for Markdown
--   `html` for HTML
--   `svg` for SVG
--   `bash` for Bash or shell scripts
--   `mdx` for MDX
--   `jsx` for JSX
--   `json` for JSON
+- `js` for Javascript code
+- `markdown` for Markdown
+- `html` for HTML
+- `svg` for SVG
+- `bash` for Bash or shell scripts
+- `mdx` for MDX
+- `jsx` for JSX
+- `json` for JSON

markdown/dev/guides/markdown/lists/en.md

@@ -12,10 +12,10 @@ To make a list, just do as you would in plain text:
   - item
 ```
 
--   a bullet
--   list
-    -   a sublist
-    -   item
+- a bullet
+- list
+  - a sublist
+  - item
 
 If you want an numbered list, just write numbers.
 They don't even have to be the correct numbers:
@@ -27,6 +27,6 @@ They don't even have to be the correct numbers:
 2. Item 3
 ```
 
-1.  Item 1
-2.  Item 2
-3.  Item 3
+1. Item 1
+2. Item 2
+3. Item 3

markdown/dev/guides/patterns/config/en.md

@@ -12,9 +12,9 @@ The pattern configuration holds important information about the pattern
 A pattern's [configuration](/reference/config/) is created by the pattern designer
 and details a number of important things about the pattern, like:
 
--   The **measurements** that are required to draft the pattern
--   The different **parts** in the pattern and how they depend on each other
--   The different **options** that are available to tweak the pattern
+- The **measurements** that are required to draft the pattern
+- The different **parts** in the pattern and how they depend on each other
+- The different **options** that are available to tweak the pattern
 
 The configuration is part of the pattern's code. It is created by the designer and
 it is the same for everybody using the pattern.

markdown/dev/guides/patterns/en.md

@@ -17,9 +17,9 @@ A schematic overview of FreeSewing
 
 If we look at our image, it can be divided into three areas:
 
--   The left area with the **settings**  box
--   The middle area with the **Pattern** box and everything in it
--   The right area with the **draft** box and the _SVG_ and _React_ logos
+- The left area with the **settings**  box
+- The middle area with the **Pattern** box and everything in it
+- The right area with the **draft** box and the _SVG_ and _React_ logos
 
 Let's take a closer look at everything that is contained within our central **Pattern** box:
 

markdown/dev/guides/patterns/paths/en.md

@@ -12,10 +12,10 @@ Paths are the lines and curves that make up your pattern.
 They are made up of a set of drawing operations that together make up the path.
 FreeSewing supports the following types of drawing operations:
 
--   The **move** operation moves our virtual pen but does not draw anything.
--   The **line** operation draws a straight line
--   The **curve** operation draws a [Bézier curve](/guides/overview/about/beziercurves/)
--   The **close** operation closes the path
+- The **move** operation moves our virtual pen but does not draw anything.
+- The **line** operation draws a straight line
+- The **curve** operation draws a [Bézier curve](/guides/overview/about/beziercurves/)
+- The **close** operation closes the path
 
 To crucial thing to keep in mind is that, with the exception of the **move** operation,
 all drawing operations start from wherever you are currently on your virtual sheet of paper.

markdown/dev/guides/patterns/points/en.md

@@ -16,8 +16,8 @@ FreeSewing pattern, and their role is to store coordinates.
 
 Each point must have:
 
--   A **X-coordinate**
--   A **Y-coordinate**
+- A **X-coordinate**
+- A **Y-coordinate**
 
 Together, these coordinates determine the location of the point in the 2-dimensional plane we're drawing on.
 

markdown/dev/guides/patterns/snippets/en.md

@@ -12,8 +12,8 @@ They are typically used for things like logos or buttons.
 
 Each snippet must have:
 
--   An anchor point that determine where the snippet will be located
--   The name of the snippet to insert
+- An anchor point that determine where the snippet will be located
+- The name of the snippet to insert
 
 Since our example image does not have any snippets in it, here's another example
 of a `button`, `buttonhole`, and `logo` snippet added to a FreeSewing pattern:

markdown/dev/guides/plugins/conditionally-loading-build-time-plugins/en.md

@@ -51,10 +51,10 @@ const Pattern = new freesewing.Design(
 
 Our condition method will return `true` only if the following conditions are met:
 
--   A `settings` object is passed into the method
--   `settings.options` is _truthy_
--   `settings.options.draftForHighBust` is _truthy_
--   `settings.options.measurements.highBust` is _truthy_
+- A `settings` object is passed into the method
+- `settings.options` is _truthy_
+- `settings.options.draftForHighBust` is _truthy_
+- `settings.options.measurements.highBust` is _truthy_
 
 This is a real-world example from our Teagan pattern. A t-shirt pattern that can be
 drafted to the high bust (rather than the full chest circumference) if the user

markdown/dev/guides/plugins/hooks/en.md

@@ -5,16 +5,16 @@ order: 60
 
 A **hook** is a lifecycle event. The available hooks are:
 
--   [preRender](/reference/hooks/prerender/): Called at the start of [`Pattern.render()`](/reference/api/pattern#render)
--   [postRender](/reference/hooks/postrender/): Called at the end of [`Pattern.render()`](/reference/api/pattern#render)
--   [insertText](/reference/hooks/inserttext/): Called when inserting text
--   [preDraft](/reference/hooks/predraft/): Called at the start of [`Pattern.draft()`](/reference/api/pattern#draft)
--   [postDraft](/reference/hooks/postdraft/): Called at the end of [`Pattern.draft()`](/reference/api/pattern#draft)
--   [preSample](/reference/hooks/presample/): Called at the start of [`Pattern.sample()`](/reference/api/pattern#sample)
--   [postSample](/reference/hooks/postsample/): Called at the end of [`Pattern.sample()`](/reference/api/pattern#sample)
+- [preRender](/reference/hooks/prerender/): Called at the start of [`Pattern.render()`](/reference/api/pattern#render)
+- [postRender](/reference/hooks/postrender/): Called at the end of [`Pattern.render()`](/reference/api/pattern#render)
+- [insertText](/reference/hooks/inserttext/): Called when inserting text
+- [preDraft](/reference/hooks/predraft/): Called at the start of [`Pattern.draft()`](/reference/api/pattern#draft)
+- [postDraft](/reference/hooks/postdraft/): Called at the end of [`Pattern.draft()`](/reference/api/pattern#draft)
+- [preSample](/reference/hooks/presample/): Called at the start of [`Pattern.sample()`](/reference/api/pattern#sample)
+- [postSample](/reference/hooks/postsample/): Called at the end of [`Pattern.sample()`](/reference/api/pattern#sample)
 
 You can register a method for a hook. When the hook is triggered, your method will be
 called. It will receive two parameters:
 
--   An object relevant to the hook. See the [hooks API reference](/reference/hooks/) for details.
--   Data passed when the hook was registered (optional)
+- An object relevant to the hook. See the [hooks API reference](/reference/hooks/) for details.
+- Data passed when the hook was registered (optional)

markdown/dev/guides/plugins/macros/en.md

@@ -5,8 +5,8 @@ order: 90
 
 Plugin structure for macros is similar, with a few changes:
 
--   Rather than the hook name, you provide the macro name (that you choose yourself)
--   The context (`this`) of a macro method is **always** a [Part](/reference/api/part) object.
+- Rather than the hook name, you provide the macro name (that you choose yourself)
+- The context (`this`) of a macro method is **always** a [Part](/reference/api/part) object.
 
 Apart from these, the structure is very similar:
 

markdown/dev/guides/plugins/plugin-structure/en.md

@@ -5,8 +5,8 @@ order: 50
 
 Plugins can do two things:
 
--   They can use hooks
--   They can provide macros
+- They can use hooks
+- They can provide macros
 
 Your plugin should export an object with the following structure:
 

markdown/dev/guides/plugins/types-of-plugins/en.md

@@ -5,8 +5,8 @@ order: 10
 
 Plugins come in two flavours:
 
--   [Build-time plugins](#build-time-plugins)
--   [Run-time plugins](#run-time-plugins)
+- [Build-time plugins](#build-time-plugins)
+- [Run-time plugins](#run-time-plugins)
 
 When writing a plugin, ask yourself whether it's a run-time or a build-time plugin.
 And if the answer is both, please split them into two plugins.

markdown/dev/guides/plugins/using-hooks/en.md

@@ -9,8 +9,8 @@ that as the second object.
 
 Remember that:
 
--   The `insertText` hook will receive a locale and string and you should return a string.
--   All other hooks receive an object. You don't need to return anything, but rather modify the object you receive.
+- The `insertText` hook will receive a locale and string and you should return a string.
+- All other hooks receive an object. You don't need to return anything, but rather modify the object you receive.
 
 Let's look at an example:
 
@@ -39,8 +39,8 @@ export default {
 
 This is a complete plugin, ready to be published on NPM. It uses two hooks:
 
--   `preRender` : We add some style and defs to our SVG
--   `insertText` : We transfer all text to UPPERCASE
+- `preRender` : We add some style and defs to our SVG
+- `insertText` : We transfer all text to UPPERCASE
 
 <Note>
 

markdown/dev/guides/prerequisites/bezier-curves/en.md

@@ -12,10 +12,10 @@ popularized their use back in the 1960s.
 
 In FreeSewing, we use so-called cubic Bézier curves which have:
 
--   A start point
--   A first control point that’s linked to the start point
--   A second control point that’s linked to the end point
--   An end point
+- A start point
+- A first control point that’s linked to the start point
+- A second control point that’s linked to the end point
+- An end point
 
 <Example settings_complete="0" part="path_curve">
 An example of a Bézier curve drawn by the Path.curve() method

markdown/dev/guides/translation/en.md

@@ -31,11 +31,11 @@ Bonus: You'll get an `@freesewing.org` email alias
 
 We currently support the following five languages:
 
--   **en** : English
--   **de** : German
--   **es** : Spanish
--   **fr** : French
--   **nl** : Dutch
+- **en** : English
+- **de** : German
+- **es** : Spanish
+- **fr** : French
+- **nl** : Dutch
 
 <Note>
 
@@ -49,8 +49,8 @@ please [come and talk to us on Discord](https://discord.freesewing.org).
 
 We use two different tools to manage our translations, depending on the context:
 
--   Markdown content and code strings in our monorepo are translated within **Crowdin**
--   Blog and showcase posts are translated within **Strapi**
+- Markdown content and code strings in our monorepo are translated within **Crowdin**
+- Blog and showcase posts are translated within **Strapi**
 
 <Tip>