Enable prettier on docs markdown (#11875)

* Enable prettier on docs markdown

* Run prettier always

---------

Co-authored-by: Sergei Garin <[email protected]>

Author: Frizi

.github/workflows/gui-checks.yml

@@ -31,17 +31,6 @@ jobs:
           node-version-file: .node-version
           cache: "pnpm"
 
-      - uses: actions/cache/restore@v4
-        name: Download cache
-        id: cache
-        with:
-          path: |
-            **/.eslintcache
-            node_modules/.cache/prettier
-          key: ${{ runner.os }}-gui-${{ github.run_id }}
-          restore-keys: |
-            ${{ runner.os }}-gui
-
       - if: startsWith(runner.name, 'GitHub Actions') || startsWith(runner.name, 'Hosted Agent')
         name: Installing wasm-pack
         uses: jetli/[email protected]
@@ -51,10 +40,15 @@ jobs:
       - name: 📦 Install dependencies
         run: pnpm install --frozen-lockfile
 
-      - name: 📝 Prettier
-        id: prettier
-        continue-on-error: true
-        run: pnpm run ci:prettier
+      - uses: actions/cache/restore@v4
+        name: Download cache
+        id: cache
+        with:
+          path: |
+            **/.eslintcache
+          key: ${{ runner.os }}-gui-${{ github.run_id }}
+          restore-keys: |
+            ${{ runner.os }}-gui
 
       # Next Tasks are depend on Typecheck, because we build libraries at this stage
       - name: 🧠 Typecheck
@@ -88,7 +82,6 @@ jobs:
       - name: ❌ Fail if any check failed
         if: always() && (steps.prettier.outcome == 'failure' || steps.lint.outcome == 'failure' || steps.typecheck.outcome == 'failure' || steps.unit-tests.outcome == 'failure')
         run: |
-          echo "Prettier outcome: ${{ steps.prettier.outcome }}"
           echo "Lint outcome: ${{ steps.lint.outcome }}"
           echo "Typecheck outcome: ${{ steps.typecheck.outcome }}"
           echo "Unit tests outcome: ${{ steps.unit-tests.outcome }}"
@@ -102,7 +95,6 @@ jobs:
           key: ${{ steps.cache.outputs.cache-primary-key }}
           path: |
             **/.eslintcache
-            node_modules/.cache/prettier
 
   playwright:
     name: 🎭 Playwright Tests

.github/workflows/gui-pull-request.yml

@@ -58,6 +58,52 @@ jobs:
             echo "$file was changed"
           done
 
+  prettier:
+    name: 🧹 Prettier
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: 📦 Setup pnpm
+        uses: pnpm/action-setup@v4
+
+      - uses: actions/setup-node@v4
+        name: ⎔ Setup Node
+        with:
+          node-version-file: .node-version
+          cache: "pnpm"
+
+      - if: startsWith(runner.name, 'GitHub Actions') || startsWith(runner.name, 'Hosted Agent')
+        name: Installing wasm-pack
+        uses: jetli/[email protected]
+        with:
+          version: v0.12.1
+
+      - name: 📦 Install dependencies
+        run: pnpm install --frozen-lockfile --ignore-scripts
+
+      - uses: actions/cache/restore@v4
+        name: Download cache
+        id: cache
+        with:
+          path: |
+            node_modules/.cache/prettier
+          key: ${{ runner.os }}-gui-${{ github.run_id }}
+          restore-keys: |
+            ${{ runner.os }}-gui
+
+      - name: Run prettier
+        run: pnpm run ci:prettier
+
+      - name: 💾 Save cache
+        uses: actions/cache/save@v4
+        if: always() && steps.cache.outputs.cache-hit != 'true'
+        id: save-cache
+        with:
+          key: ${{ steps.cache.outputs.cache-primary-key }}
+          path: |
+            node_modules/.cache/prettier
+
   checks:
     name: 🧰 Checks
     uses: ./.github/workflows/gui-checks.yml

.prettierignore

@@ -16,7 +16,6 @@ distribution/lib/Standard/*/*/manifest.yaml
 distribution/lib/Standard/*/*/polyglot
 distribution/lib/Standard/*/*/THIRD-PARTY
 distribution/docs-js
-docs/**/*.md
 
 built-distribution/
 THIRD-PARTY

docs/semantics/errors.md

@@ -20,8 +20,7 @@ users to deal with errors at runtime in the language.
 
 ## Asynchronous Exceptions
 
-> [!WARNING]
-> The actionables for this section are:
+> [!WARNING] The actionables for this section are:
 >
 > - Why do we call it asynchronous, when they are synchronous!?
 > - Specify the semantics of Enso's async exceptions.
@@ -32,19 +31,16 @@ There is a special [dynamic dispatch](../types/dynamic-dispatch.md) for `Error`
 values. A dataflow error dispatch first checks if it may call a method on
 `Error` type.
 
-> [!WARNING]
-> The actionables for this section are:
+> [!WARNING] The actionables for this section are:
 >
 > - Specify the semantics of Enso's broken values.
 
 ## Warnings
 
-> [!WARNING]
-> TODO
+> [!WARNING] TODO
 >
 > - Values in Enso may have warnings attached
 
 There is a special [dynamic dispatch](../types/dynamic-dispatch.md) for _values
-with warnings_. Before we pass the dispatch to the underlying value,
-we check if warning has a method 'overridden' - this is used for `remove_warnings`,
-etc.
+with warnings_. Before we pass the dispatch to the underlying value, we check if
+warning has a method 'overridden' - this is used for `remove_warnings`, etc.

docs/syntax/README.md

@@ -43,7 +43,8 @@ The various components of Enso's syntax are described below:
 - [**Functions:**](./functions.md) The syntax for writing functions in Enso.
 - [**Function Arguments:**](./function-arguments.md) The syntax for function
   arguments in Enso.
-- [**Conversions:**](./conversions.md) The syntax of special _conversion functions_ in Enso.
+- [**Conversions:**](./conversions.md) The syntax of special _conversion
+  functions_ in Enso.
 - [**Field Access:**](./projections.md) The syntax for working with fields of
   data types in Enso.
 - [**Comments:**](./comments.md) The syntax for writing comments in Enso.

docs/syntax/conversions.md

@@ -8,28 +8,36 @@ order: 10
 
 # Conversions
 
-Conversions are special [functions](./functions.md) associated with a [type](../types/hierarchy.md),
-named `from` and taking single `that` argument. Following example:
+Conversions are special [functions](./functions.md) associated with a
+[type](../types/hierarchy.md), named `from` and taking single `that` argument.
+Following example:
+
 ```ruby
 type Complex
     Num re:Float im:Float
 
 Complex.from (that:Float) = Complex.Num that 0
 ```
-defines type `Complex` and a **conversion** from `Float` which uses the provided `Float` value as
-real part of a complex number while setting the imaginary part to zero.
+
+defines type `Complex` and a **conversion** from `Float` which uses the provided
+`Float` value as real part of a complex number while setting the imaginary part
+to zero.
 
 ## Type Checks
 
-Conversions are integral part of [type checking](../types/inference-and-checking.md#type-checking-algorithm)
+Conversions are integral part of
+[type checking](../types/inference-and-checking.md#type-checking-algorithm)
 during runtime. Having the right conversion in scope one can write:
+
 ```ruby
 complex_pi = 3.14:Complex
 ```
-to create a new instance of type `Complex`. The Enso runtime represents
-the `3.14` literal as `Float` value and that would fail the `Complex` type check if there was no
-conversion method available. However as there is one, the runtime uses `Complex.from` behind the
-scene and `complex_pi` then becomes `Complex.Num 3.14 0` value.
 
-Type checks may perform no, one or multiple conversions (like in case of 
+to create a new instance of type `Complex`. The Enso runtime represents the
+`3.14` literal as `Float` value and that would fail the `Complex` type check if
+there was no conversion method available. However as there is one, the runtime
+uses `Complex.from` behind the scene and `complex_pi` then becomes
+`Complex.Num 3.14 0` value.
+
+Type checks may perform no, one or multiple conversions (like in case of
 [intersection types](../types/intersection-types.md)).

docs/types/README.md

@@ -39,8 +39,7 @@ instrumental for ensuring that we build the right language.
 > described in the [syntax](../syntax/README.md) document makes no promises as
 > to whether said syntax will be exposed in the surface language.
 
-> [!WARNING]
-> The specification in this section is very outdated and far from
+> [!WARNING] The specification in this section is very outdated and far from
 > reality. Sections that are known to be _"off"_ are marked as _warning_.
 
 Information on the type system is broken up into the following sections:

docs/types/access-modifiers.md

@@ -8,23 +8,23 @@ order: 4
 
 # Access Modifiers
 
-> [!WARNING]
-> Everybody who ever maintained a large system knows [encapsulation is essential](../semantics/encapsulation.md).
+> [!WARNING] Everybody who ever maintained a large system knows
+> [encapsulation is essential](../semantics/encapsulation.md).
 >
-> While we don't usually like making things private in a programming language, it
-> sometimes the case that it is necessary to indicate that certain fields should
-> not be touched (as this might break invariants and such like). To this end, Enso
-> provides an explicit mechanism for access modification.
+> While we don't usually like making things private in a programming language,
+> it sometimes the case that it is necessary to indicate that certain fields
+> should not be touched (as this might break invariants and such like). To this
+> end, Enso provides an explicit mechanism for access modification.
 
 Enso targets large user base of _non-programmers_. They are mostly focused on
-getting their job done and [encapsulation](../semantics/encapsulation.md) of their own code is the last thing
-that comes to their mind.
+getting their job done and [encapsulation](../semantics/encapsulation.md) of
+their own code is the last thing that comes to their mind.
 
-On the other hand, Enso supports and encourages creation of *sharable libraries*.
-Maintainers of such libraries are likely to treat API design and its
-backward compatibility seriously. As such they need a way to [encapsulate](../semantics/encapsulation.md)
-internals of their libraries and clearly *differentiate public API* and
-implementations details.
+On the other hand, Enso supports and encourages creation of _sharable
+libraries_. Maintainers of such libraries are likely to treat API design and its
+backward compatibility seriously. As such they need a way to
+[encapsulate](../semantics/encapsulation.md) internals of their libraries and
+clearly _differentiate public API_ and implementations details.
 
 <!-- MarkdownTOC levels="2,3" autolink="true" -->
 
@@ -35,27 +35,26 @@ implementations details.
 
 ## Access Modification
 
-*By default* Enso elements (functions, types, methods) are *public*.
-One has to use an access modifier to hide and [encapsulate](../semantics/encapsulation.md) them. The
-reasoning is: those who don't care can access everything they create without
-any restriction. Those who care can make things `private` with an additional
-effort.
+_By default_ Enso elements (functions, types, methods) are _public_. One has to
+use an access modifier to hide and [encapsulate](../semantics/encapsulation.md)
+them. The reasoning is: those who don't care can access everything they create
+without any restriction. Those who care can make things `private` with an
+additional effort.
 
+Accessing any member under an access modifier is an error when performed from
+another project. Such a check is enforced during runtime.
 
-Accessing any member under an access modifier is an error when performed from another project.
-Such a check is enforced during runtime.
-
-There is a command line switch to _disable access modifier check_.
-It maybe be useful for experimentation. However the general suggestion is:
-Avoid using it in production.
+There is a command line switch to _disable access modifier check_. It maybe be
+useful for experimentation. However the general suggestion is: Avoid using it in
+production.
 
 ## Private
 
 Encapsulation is an effective _communication mechanism_ among _distributed
-groups_ of developers. The `private` modifier hides implementation details from clients of the API.
-The primary groups in the Enso case are those who *publish a library*
-and those who *consume such a library*.
+groups_ of developers. The `private` modifier hides implementation details from
+clients of the API. The primary groups in the Enso case are those who _publish a
+library_ and those who _consume such a library_.
 
-As such Enso supports _library private_ encapsulation.
-To hide any element (module, type, constructor, function) away
-from *library consumers* prefix such an element with `private` keyword.
+As such Enso supports _library private_ encapsulation. To hide any element
+(module, type, constructor, function) away from _library consumers_ prefix such
+an element with `private` keyword.