Change prettier to a direct node use. (#4550)

The prettier pre-commit mirror is no longer supported
(https://github.com/pre-commit/mirrors-prettier). This switches to a
direct call, and updates to 3.3.3. And I'm now specifying types for it
to apply to, rather than letting it ignore unknown files; overall just
trying to separate out which linter sees what.

To comment on formatting changes:

- In most cases, seems to be getting confused by `[]` use in markdown
when it's not part of a link. This looks like a regression, but not one
we're broadly affected by.
- p0107.md - caught an issue with a malformed broken bad link which I've
tried to fix.
- p3720.md - looks like a fix.

Note, prettier has a 4.0.0 alpha release. As best as I could tell, that
only affected the .prettierrc.yaml processing. I changed the glob there
for forwards compatibility.

.pre-commit-config.yaml

@@ -48,10 +48,14 @@ repos:
     rev: 1b2427a2b785cc4aac97c19bb4b9a0de063f9547 # frozen: 24.10.0
     hooks:
       - id: black
-  - repo: https://github.com/pre-commit/mirrors-prettier
-    rev: ffb6a759a979008c0e6dff86e39f4745a2d9eac4 # frozen: v3.1.0
+  - repo: local
     hooks:
       - id: prettier
+        name: prettier
+        language: node
+        additional_dependencies: ['prettier@3.3.3']
+        types_or: [html, javascript, markdown, yaml]
+        entry: npx prettier --write --log-level=warn
   - repo: local
     hooks:
       - id: buildifier

.prettierrc.yaml

@@ -9,6 +9,6 @@ tabWidth: 2
 trailingComma: 'es5'
 useTabs: false
 overrides:
-  - files: '*.md'
+  - files: '**/*.md'
     options:
       tabWidth: 4

docs/design/pattern_matching.md

@@ -335,7 +335,8 @@ _pattern_ `=` _expression_ `;`.
 A tuple of patterns can be used as a pattern.
 
 -   _tuple-pattern_ ::= `(` [_expression_ `,`]\* _proper-pattern_ [`,`
-    _pattern_]\* `,`? `)`
+    _pattern_]\*
+    `,`? `)`
 -   _proper-pattern_ ::= _tuple-pattern_
 
 A _tuple-pattern_ containing no commas is treated as grouping parens: the
@@ -355,7 +356,8 @@ compares fields left-to-right.
 A struct can be matched with a struct pattern.
 
 -   _proper-pattern_ ::= `{` [_field-init_ `,`]\* _proper-field-pattern_ [`,`
-    _field-pattern_]\* `}`
+    _field-pattern_]\*
+    `}`
 -   _proper-pattern_ ::= `{` [_field-pattern_ `,`]+ `_` `}`
 -   _field-init_ ::= _designator_ `=` _expression_
 -   _proper-field-pattern_ ::= _designator_ `=` _proper-pattern_

docs/design/values.md

@@ -674,8 +674,8 @@ alternatives considered section of [P2006]:
 ### Pointer syntax
 
 The type of a pointer to a type `T` is written with a postfix `*` as in `T*`.
-Dereferencing a pointer is a [_reference expression_] and is written with a
-prefix `*` as in `*p`:
+Dereferencing a pointer is a [_reference expression_] and is written with a prefix
+`*` as in `*p`:
 
 ```carbon
 var i: i32 = 42;

proposals/p0107.md

@@ -553,10 +553,10 @@ We could instead use `.` for library names and `/` for packages, such as
 Advantages:
 
 -   Clearer distinction between the package and library, increasing readability.
--   We have chosen not to [enforce file system
-    paths](#strict-association-between-the-file
-    system-path-and-librarynamespace) in order to ease refactoring, and
-    encouraging a mental model where they may match could confuse users.
+-   We have chosen not to
+    [enforce file system paths](#should-there-be-a-tight-association-between-file-paths-and-packageslibraries)
+    in order to ease refactoring, and encouraging a mental model where they may
+    match could confuse users.
 
 Disadvantages:
 

proposals/p1083.md

@@ -286,12 +286,12 @@ Disadvantages:
         expectations, for example in some important bit-manipulation cases.
     -   Give integer types a range of values rather than simply a bit-width. For
         example, we can say that negation on `i32` produces a type that can
-        represent [-2<sup>31</sup>+1, 2<sup>31</sup>], which still fits in 32
-        bits. However, this would add significant complexity to the type system,
-        and with this approach, division would still increase the bit width: for
-        example, `a / b`, where `a` and `b` are `iN`s, has 2<sup>`N`</sup>+1
-        distinct possible values. This is especially surprising because integer
-        division is usually expected to make a number smaller!
+        represent [-2<sup>31</sup>+1, 2<sup>31</sup>], which still fits in 32 bits.
+        However, this would add significant complexity to the type system, and with
+        this approach, division would still increase the bit width: for example,
+        `a / b`, where `a` and `b` are `iN`s, has 2<sup>`N`</sup>+1 distinct possible
+        values. This is especially surprising because integer division is usually
+        expected to make a number smaller!
 -   Refactoring code becomes more challenging, as the appropriate intermediate
     type must be determined. Mitigating this, the type system would inform the
     programmer when they make a mistake.
@@ -379,9 +379,9 @@ cases are:
     difference of such unsigned quantities, and it's generally preferable for
     such subtractions to produce a negative result rather than a subtle bug.
     Moreover, while a restriction to non-negative values is common, supporting
-    only the case of a range restriction to [0, 2<sup>N</sup>-1], but not any
-    other range, does not do a good job of addressing the general desire to
-    capture intent and to make invalid states unrepresentable.
+    only the case of a range restriction to [0, 2<sup>N</sup>-1], but not any other
+    range, does not do a good job of addressing the general desire to capture intent
+    and to make invalid states unrepresentable.
 -   Ability to reduce storage size. Spending a sign bit every time a number is
     stored, even when it's known to be non-negative is wasteful. This is an
     important concern, and one we should address, but it's thought to be better

proposals/p2188.md

@@ -362,7 +362,8 @@ _pattern_ `=` _expression_ `;`.
 A tuple of patterns can be used as a pattern.
 
 -   _tuple-pattern_ ::= `(` [_expression_ `,`]\* _proper-pattern_ [`,`
-    _pattern_]\* `,`? `)`
+    _pattern_]\*
+    `,`? `)`
 -   _proper-pattern_ ::= _tuple-pattern_
 
 A _tuple-pattern_ containing no commas is treated as grouping parens: the
@@ -382,7 +383,8 @@ compares fields left-to-right.
 A struct can be matched with a struct pattern.
 
 -   _proper-pattern_ ::= `{` [_field-init_ `,`]\* _proper-field-pattern_ [`,`
-    _field-pattern_]\* `}`
+    _field-pattern_]\*
+    `}`
 -   _proper-pattern_ ::= `{` [_field-pattern_ `,`]+ `_` `}`
 -   _field-init_ ::= _designator_ `=` _expression_
 -   _proper-field-pattern_ ::= _designator_ `=` _proper-pattern_

proposals/p2550.md

@@ -103,8 +103,8 @@ provide a `main` function that is used as the entry point.
 In the `Main` package, the package declaration does not explicitly specify a
 package name. The package declaration syntax becomes:
 
--   `package` _Foo_ [`library "`_Bar_`"`] \(`api` | `impl`) `;`, unchanged from
-    #107, for a file that is part of a package other than the `Main` package.
+-   `package` _Foo_ [`library "`_Bar_`"`] \(`api` | `impl`) `;`, unchanged from #107,
+    for a file that is part of a package other than the `Main` package.
 -   `library "`_Bar_`"` (`api` | `impl`) `;` for a library that is part of the
     `Main` package.
 -   Omitted entirely for an `impl` file in the `Main` package that is not part

proposals/p3564.md

@@ -56,10 +56,9 @@ evaluation. We executed on this really well, but with mixed results.
     https://github.com/carbon-language/carbon-lang/blob/840cb1bed7cf9bd57e000cb4a61e986c383d3038/docs/project/roadmap.md
 
 On getting ready for evaluation, we made fantastic progress on getting the
-language (design) ready. We have [milestone definitions], and closed the most
-critical gaps in the design from the start of the year. The remaining gaps are
-either lower risk, almost finished, or really need interop to effectively
-explore.
+language (design) ready. We have [milestone definitions], and closed the most critical
+gaps in the design from the start of the year. The remaining gaps are either lower
+risk, almost finished, or really need interop to effectively explore.
 
 [milestone definitions]: /docs/project/milestones.md
 

proposals/p3720.md

@@ -229,8 +229,8 @@ Assert((r as __Binding_C_Static).(Call(()).Op)() == 2);
 How does this arise?
 
 1. First the simple member access is resolved using the type of the receiver: \
-   `v.F` -> `v.(C.F)`, `v.Static` -> `v.(C.Static)`, `r.F` -> `r.(C.F)`, `r.Static`
-   -> `r.(C.Static)`. \
+   `v.F` -> `v.(C.F)`, `v.Static` -> `v.(C.Static)`, `r.F` -> `r.(C.F)`,
+   `r.Static` -> `r.(C.Static)`. \
    Note that `C.F` is `__C_F` with type `__TypeOf_C_F`, and `C.Static` is
    `__C_Static` with type `__TypeOf_C_Static`.
 2. It then looks at the expression to the left of the `.`: