fix: align prettier v2 -> v3 to match pre-release workflow

jstvz · jstvz · commit ab20b6ed7f35 · 2026-04-10T15:48:10.000-07:00
Root cause of recurring lint failures on release PRs: the pre-release
workflow installed latest prettier (v3.x) to format docs/history.md,
but the pre-commit hook pinned mirrors-prettier at v2.5.1. The v2/v3
formatting differences caused the pre-commit check to fail.

- Bump mirrors-prettier from v2.5.1 to v3.1.0 in .pre-commit-config.yaml
- Pin workflow to `prettier@3` to prevent future drift
- Add vendored assets (docs/diagram/, minified files) and Jinja
  templates to .prettierignore
- One-time reformat of markdown/yaml/html files to v3 rules
diff --git a/.github/workflows/pre-release.yml b/.github/workflows/pre-release.yml
@@ -54,7 +54,7 @@ jobs:
                   python utility/update-history.py
             - name: Lint history
               run: |
-                  npm install prettier
+                  npm install prettier@3
                   npx prettier --write docs/history.md
             - name: Commit changes
               run: |
diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
@@ -23,7 +23,7 @@ repos:
           - id: isort
             args: ["--profile", "black", "--filter-files"]
     - repo: https://github.com/pre-commit/mirrors-prettier
-      rev: v2.5.1
+      rev: v3.1.0
       hooks:
           - id: prettier
     - repo: local
diff --git a/.prettierignore b/.prettierignore
@@ -1 +1,5 @@
-Test*.yaml
+Test*.yaml
+docs/diagram/
+**/*.min.js
+**/*.min.css
+cumulusci/files/templates/
diff --git a/.readthedocs.yml b/.readthedocs.yml
@@ -27,7 +27,7 @@ sphinx:
 formats:
     - pdf
     - epub
-  # Optionally declare the Python requirements required to build your docs
+    # Optionally declare the Python requirements required to build your docs
 # python:
 #     install:
 #         - requirements: requirements_dev.txt
diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
@@ -35,23 +35,23 @@ socioeconomic status, or other similar personal characteristics.
 Examples of behavior that contributes to creating a positive environment
 include:
 
-* Using welcoming and inclusive language
-* Being respectful of differing viewpoints and experiences
-* Gracefully accepting constructive criticism
-* Focusing on what is best for the community
-* Showing empathy toward other community members
+-   Using welcoming and inclusive language
+-   Being respectful of differing viewpoints and experiences
+-   Gracefully accepting constructive criticism
+-   Focusing on what is best for the community
+-   Showing empathy toward other community members
 
 Examples of unacceptable behavior by participants include:
 
-* The use of sexualized language or imagery and unwelcome sexual attention or
-advances
-* Personal attacks, insulting/derogatory comments, or trolling
-* Public or private harassment
-* Publishing, or threatening to publish, others' private information—such as
-a physical or electronic address—without explicit permission
-* Other conduct which could reasonably be considered inappropriate in a
-professional setting
-* Advocating for or encouraging any of the above behaviors
+-   The use of sexualized language or imagery and unwelcome sexual attention or
+    advances
+-   Personal attacks, insulting/derogatory comments, or trolling
+-   Public or private harassment
+-   Publishing, or threatening to publish, others' private information—such as
+    a physical or electronic address—without explicit permission
+-   Other conduct which could reasonably be considered inappropriate in a
+    professional setting
+-   Advocating for or encouraging any of the above behaviors
 
 ## Our Responsibilities
 
@@ -98,7 +98,7 @@ It includes adaptions and additions from [Go Community Code of Conduct][golang-c
 
 This Code of Conduct is licensed under the [Creative Commons Attribution 3.0 License][cc-by-3-us].
 
-[contributor-covenant-home]: https://www.contributor-covenant.org (https://www.contributor-covenant.org/)
+[contributor-covenant-home]: https://www.contributor-covenant.org "https://www.contributor-covenant.org/"
 [golang-coc]: https://golang.org/conduct
 [cncf-coc]: https://github.com/cncf/foundation/blob/master/code-of-conduct.md
 [microsoft-coc]: https://opensource.microsoft.com/codeofconduct/
diff --git a/SECURITY.md b/SECURITY.md
@@ -4,4 +4,4 @@ Please report any security issue to [security@salesforce.com](mailto:security@sa
 as soon as it is discovered. This library limits its runtime dependencies in
 order to reduce the total cost of ownership as much as can be, but all consumers
 should remain vigilant and have their security stakeholders review all third-party
-products (3PP) like this one and their dependencies.
+products (3PP) like this one and their dependencies.
diff --git a/cumulusci/robotframework/tests/salesforce/labels.html b/cumulusci/robotframework/tests/salesforce/labels.html
@@ -1,4 +1,4 @@
-<!DOCTYPE html>
+<!doctype html>
 <html lang="en">
     <head>
         <title>Labels for testing</title>
diff --git a/cumulusci/tasks/push/README.md b/cumulusci/tasks/push/README.md
@@ -1,21 +1,20 @@
 # Push Upgrade API Scripts
 
-These scripts are designed to work with the Salesforce Push Upgrade API (in Pilot in Winter 16) which exposes new objects via the Tooling API that allow interacting with push upgrades in a packaging org.  The main purpose of these scripts is to use the Push Upgrade API to automate push upgrades through Jenkins.
+These scripts are designed to work with the Salesforce Push Upgrade API (in Pilot in Winter 16) which exposes new objects via the Tooling API that allow interacting with push upgrades in a packaging org. The main purpose of these scripts is to use the Push Upgrade API to automate push upgrades through Jenkins.
 
 # push_api.py - Python Wrapper for Push Upgrade API
 
-This python file provides wrapper classes around the Tooling API objects and abstracts interaction with them and their related data to make writing scripts easier.  All the other scripts in this directory use the SalesforcePushApi wrapper to interact with the Tooling API.
+This python file provides wrapper classes around the Tooling API objects and abstracts interaction with them and their related data to make writing scripts easier. All the other scripts in this directory use the SalesforcePushApi wrapper to interact with the Tooling API.
 
 Initializing the SalesforcePushApi wrapper can be done with the following python code:
 
     push_api = SalesforcePushApi(sf_user, sf_pass, sf_serverurl)
 
 You can also pass two optional keyword args to the initialization to control the wrapper's behavior
-    
-* **lazy**: A list of objects that should be lazily looked up.  Currently, the only implementations for this are 'jobs' and 'subscribers'.  If either are included in the list, they will be looked up on demand when needed by a referenced object.  For example, if you are querying all jobs and subscribers is not set to lazy, all subscribers will first be retrieved.  If lazy is enabled, subscriber orgs will only be retrieved when trying to resolve references for a particular job.  Generally, if you have a lot of subscribers and only expect your script to need to lookup a small number of them, enabling lazy for subscribers will reduce api calls and cause the script to run faster.
 
-* **default_where**: A dictionary with Push Upgrade API objects as key and a value containing a SOQL WHERE clause statement which is applied to all queries against the object to effectively set the universe for a given object.  For example:
-    
+-   **lazy**: A list of objects that should be lazily looked up. Currently, the only implementations for this are 'jobs' and 'subscribers'. If either are included in the list, they will be looked up on demand when needed by a referenced object. For example, if you are querying all jobs and subscribers is not set to lazy, all subscribers will first be retrieved. If lazy is enabled, subscriber orgs will only be retrieved when trying to resolve references for a particular job. Generally, if you have a lot of subscribers and only expect your script to need to lookup a small number of them, enabling lazy for subscribers will reduce api calls and cause the script to run faster.
+
+-   **default_where**: A dictionary with Push Upgrade API objects as key and a value containing a SOQL WHERE clause statement which is applied to all queries against the object to effectively set the universe for a given object. For example:
     default_where = {'PackageSubscriber': "OrgType = 'Sandbox'"}
 
 In the example above, the wrapper would never return a PackageSubscriber which is not a Sandbox org.
@@ -24,36 +23,35 @@ In the example above, the wrapper would never return a PackageSubscriber which i
 
 ## Common Environment Variables
 
-The push scripts are all designed to receive their arguments via environment variables.  The following are common amongst all of the Push Scripts
+The push scripts are all designed to receive their arguments via environment variables. The following are common amongst all of the Push Scripts
 
-* **SF_USERNAME**: The Salesforce username for the packaging org
-* **SF_PASSWORD**: The Salesforce password and security token for the packaging org
-* **SF_SERVERURL**: The login url for the Salesforce packaging org.
+-   **SF_USERNAME**: The Salesforce username for the packaging org
+-   **SF_PASSWORD**: The Salesforce password and security token for the packaging org
+-   **SF_SERVERURL**: The login url for the Salesforce packaging org.
 
 ## get_version_id.py
 
-Takes a namespace and version string and looks up the given version.  Returns the version's Salesforce Id.
+Takes a namespace and version string and looks up the given version. Returns the version's Salesforce Id.
 
 The script handles parsing the version number string into a SOQL query against the MetadataPackageVersion object with the correct MajorVersion, MinorVersion, PatchVersion, ReleaseState, and BuildNumber (i.e. Beta number).
 
 ### Required Environment Variables
 
-* **NAMESPACE**: The Package's namespace prefix
-* **VERSION_NUMBER**: The version number string.
+-   **NAMESPACE**: The Package's namespace prefix
+-   **VERSION_NUMBER**: The version number string.
 
 ## orgs_for_push.py
 
 Takes a MetadataPackageVersion Id and optionally a where clause to filter Subscribers and returns a list of OrgId's one per line which can be fed into the schedule_push.py script.
 
 ### Required Environment Variables
 
-* **VERSION**: The MetadataPackageVersion Id of the version you want to push upgrade.  This is used to look for all users not on the version or a newer version
+-   **VERSION**: The MetadataPackageVersion Id of the version you want to push upgrade. This is used to look for all users not on the version or a newer version
 
 ### Optional Environment Variables
 
-* **SUBSCRIBER_WHERE**: An extra filter to be applied to all Subscriber queries.  For example, setting this to OrgType = 'Sandbox' would find all Sandbox orgs eligible for push upgrade to the specified version
+-   **SUBSCRIBER_WHERE**: An extra filter to be applied to all Subscriber queries. For example, setting this to OrgType = 'Sandbox' would find all Sandbox orgs eligible for push upgrade to the specified version
 
 ## failed_orgs_for_push.py
 
-Takes a PackagePushRequest Id and optionally a where clause to filter Subscribers and returns a list of OrgId's one per line for all orgs which failed the 
-
+Takes a PackagePushRequest Id and optionally a where clause to filter Subscribers and returns a list of OrgId's one per line for all orgs which failed the
diff --git a/cumulusci/tasks/release_notes/README.md b/cumulusci/tasks/release_notes/README.md
@@ -13,25 +13,25 @@ Start the section with `# Critical Changes` followed by your content
 For example:
 
     This won't be included
-    
+
     # Critical Changes
-    
+
     This will be included in Critical Changes
-    
+
 ## Changes
 
-The Changes section is where you should list off any changes worth highlight to users in the release notes.  This section should always include instructions for users for any post-upgrade tasks they need to perform to enable new functionality.  For example, users should be told to grant permissions and add new CustomFields to layouts.
+The Changes section is where you should list off any changes worth highlight to users in the release notes. This section should always include instructions for users for any post-upgrade tasks they need to perform to enable new functionality. For example, users should be told to grant permissions and add new CustomFields to layouts.
 
 Start the section with `# Changes` followed by your content
 
 For example:
 
     This won't be included
-    
+
     # Changes
-    
+
     This will be included in Changes
-    
+
 ## Issues Closed
 
 The Issues Closed section is where you should link to any closed issues that should be listed in the release notes.
@@ -41,9 +41,9 @@ Start the section with `# Changes` followed by your content
 For example:
 
     This won't be included
-    
+
     # Issues Closed
-    
+
     Fixes #102
     resolves #100
     This release closes #101
@@ -55,9 +55,9 @@ Would output:
     #100: Title of Issue 100
     #101: Title of Issue 101
     #102: Title of Issue 102
-    
+
 A few notes about how issues are parsed:
 
-* The parser uses the same format as Github: https://help.github.com/articles/closing-issues-via-commit-messages/
-* The parser searches for all issue numbers and sorts them by their integer value, looks up their title, and outputs a formatted line with the issue number and title for each issue.
-* The parser ignores everything else in the line that is not an issue number.  Anything that is not an issue number will not appear in the rendered release notes
+-   The parser uses the same format as Github: https://help.github.com/articles/closing-issues-via-commit-messages/
+-   The parser searches for all issue numbers and sorts them by their integer value, looks up their title, and outputs a formatted line with the issue number and title for each issue.
+-   The parser ignores everything else in the line that is not an issue number. Anything that is not an issue number will not appear in the rendered release notes
diff --git a/cumulusci/tasks/release_notes/tests/change_notes/full/example1.md b/cumulusci/tasks/release_notes/tests/change_notes/full/example1.md
@@ -2,15 +2,14 @@ This is my pull request comment. Just explaining some stuff I did here, but shou
 
 # Critical Changes
 
-* This will break everything!
+-   This will break everything!
 
 # Changes
 
 Here's something I did. It was really cool
 
 Oh yeah I did something else too!
 
-
 # Issues Closed
 
 Fixed #2345 that was a real pain
diff --git a/cumulusci/tasks/robotframework/template.html b/cumulusci/tasks/robotframework/template.html
@@ -1,4 +1,4 @@
-<!DOCTYPE html>
+<!doctype html>
 <html lang="en">
     <head>
         <meta charset="utf-8" />
diff --git a/cumulusci/utils/http/tests/cassettes/ManualEditTestCompositeParallelSalesforce.test_http_headers.yaml b/cumulusci/utils/http/tests/cassettes/ManualEditTestCompositeParallelSalesforce.test_http_headers.yaml
@@ -1,32 +1,33 @@
 interactions:
-- request:
-    body: '{"compositeRequest": [{"referenceId": "CCI__RefId__0__", "method": "GET",
-      "url": "/services/data/v49.0/sobjects", "httpHeaders": {"If-Modified-Since":
-      "Thu, 03 Sep 2020 21:35:07 GMT"}}, {"referenceId": "CCI__RefId__1__", "method":
-      "GET", "url": "/services/data/v49.0/sobjects", "httpHeaders": {"If-Modified-Since":
-      "Thu, 03 Sep 2020 21:35:07 GMT"}}, {"referenceId": "CCI__RefId__2__", "method":
-      "GET", "url": "/services/data/v49.0/sobjects", "httpHeaders": {"If-Modified-Since":
-      "Thu, 03 Sep 2020 21:35:07 GMT"}}]}'
-    headers:
-      Request-Headers:
-      - Elided
-    method: POST
-    uri: https://orgname.my.salesforce.com/services/data/v49.0/composite
-  response:
-    body:
-      string: "{\n  \"compositeResponse\" : [ {\n    \"body\" : null,\n    \"httpHeaders\"
-        : {\n      \"ETag\" : \"\\\"baf7f695\\\"\",\n      \"Last-Modified\" : \"Fri,
-        14 Aug 2020 20:53:02 GMT\"\n    },\n    \"httpStatusCode\" : 304,\n    \"referenceId\"
-        : \"CCI__RefId__0__\"\n  }, {\n    \"body\" : null,\n    \"httpHeaders\" :
-        {\n      \"ETag\" : \"\\\"baf7f695\\\"\",\n      \"Last-Modified\" : \"Fri,
-        14 Aug 2020 20:53:02 GMT\"\n    },\n    \"httpStatusCode\" : 304,\n    \"referenceId\"
-        : \"CCI__RefId__1__\"\n  }, {\n    \"body\" : null,\n    \"httpHeaders\" :
-        {\n      \"ETag\" : \"\\\"baf7f695\\\"\",\n      \"Last-Modified\" : \"Fri,
-        14 Aug 2020 20:53:02 GMT\"\n    },\n    \"httpStatusCode\" : 304,\n    \"referenceId\"
-        : \"CCI__RefId__2__\"\n  } ]\n}"
-    headers:
-      Response-Headers: Elided
-    status:
-      code: 200
-      message: OK
+    - request:
+          body: '{"compositeRequest": [{"referenceId": "CCI__RefId__0__", "method": "GET",
+              "url": "/services/data/v49.0/sobjects", "httpHeaders": {"If-Modified-Since":
+              "Thu, 03 Sep 2020 21:35:07 GMT"}}, {"referenceId": "CCI__RefId__1__", "method":
+              "GET", "url": "/services/data/v49.0/sobjects", "httpHeaders": {"If-Modified-Since":
+              "Thu, 03 Sep 2020 21:35:07 GMT"}}, {"referenceId": "CCI__RefId__2__", "method":
+              "GET", "url": "/services/data/v49.0/sobjects", "httpHeaders": {"If-Modified-Since":
+              "Thu, 03 Sep 2020 21:35:07 GMT"}}]}'
+          headers:
+              Request-Headers:
+                  - Elided
+          method: POST
+          uri: https://orgname.my.salesforce.com/services/data/v49.0/composite
+      response:
+          body:
+              string:
+                  "{\n  \"compositeResponse\" : [ {\n    \"body\" : null,\n    \"httpHeaders\"
+                  : {\n      \"ETag\" : \"\\\"baf7f695\\\"\",\n      \"Last-Modified\" : \"Fri,
+                  14 Aug 2020 20:53:02 GMT\"\n    },\n    \"httpStatusCode\" : 304,\n    \"referenceId\"
+                  : \"CCI__RefId__0__\"\n  }, {\n    \"body\" : null,\n    \"httpHeaders\" :
+                  {\n      \"ETag\" : \"\\\"baf7f695\\\"\",\n      \"Last-Modified\" : \"Fri,
+                  14 Aug 2020 20:53:02 GMT\"\n    },\n    \"httpStatusCode\" : 304,\n    \"referenceId\"
+                  : \"CCI__RefId__1__\"\n  }, {\n    \"body\" : null,\n    \"httpHeaders\" :
+                  {\n      \"ETag\" : \"\\\"baf7f695\\\"\",\n      \"Last-Modified\" : \"Fri,
+                  14 Aug 2020 20:53:02 GMT\"\n    },\n    \"httpStatusCode\" : 304,\n    \"referenceId\"
+                  : \"CCI__RefId__2__\"\n  } ]\n}"
+          headers:
+              Response-Headers: Elided
+          status:
+              code: 200
+              message: OK
 version: 1
diff --git a/docs/about.md b/docs/about.md
@@ -5,4 +5,4 @@
 
 contributing
 history
-```
+```
diff --git a/docs/config.md b/docs/config.md
@@ -86,7 +86,9 @@ Options
     Require at least X percent code coverage across the org following the test run.
     Default: 90
 ```
+
 (add-a-custom-task)=
+
 ### Add a Custom Task
 
 To define a new task for your project, add the task name under the
diff --git a/docs/cumulusci-flow.md b/docs/cumulusci-flow.md
@@ -296,6 +296,7 @@ child branches. This means that despite
 not receive automerges until the parent branch tests successfully.
 
 (release-to-future-release-merges)=
+
 ### Release to (Future) Release Merges
 
 Because release branches are so long-lived, and so much work goes into
diff --git a/docs/data.md b/docs/data.md
@@ -816,13 +816,15 @@ Extract the data for a dataset from an org and persist it to disk.
 
 `mapping` and either `sql_path` or `database_url` must be supplied.
 
-Example: 
+Example:
+
 ```console
 cci task run extract_dataset -o mapping datasets/qa/mapping.yml -o sql_path datasets/qa/data.sql --org qa
 ```
 
 (data-load-dataset)=
-###  `load_dataset`
+
+### `load_dataset`
 
 Load the data for a dataset into an org. If the storage is a database,
 persist new Salesforce Ids to storage.
@@ -842,7 +844,7 @@ persist new Salesforce Ids to storage.
 
 `mapping` and either `sql_path` or `database_url` must be supplied.
 
-Example: 
+Example:
 
 ```console
 cci task run load_dataset -o mapping datasets/qa/mapping.yml -o sql_path datasets/qa/data.sql --org qa
@@ -912,7 +914,7 @@ after their target records become available.
 -   `namespace_prefix`: The namespace prefix to treat as belonging to
     the project, if any
 
-Example: 
+Example:
 
 ```console
 cci task run generate_dataset_mapping --org qa -o namespace_prefix my_ns
diff --git a/docs/deploy.md b/docs/deploy.md
@@ -1,4 +1,5 @@
 (configure-metadata-deployment)=
+
 # Configure Metadata Deployment
 
 CumulusCI's `deploy` task uses the Metadata API to deploy metadata from the repository to a Salesforce org. `deploy` offers multiple sophisticated capabilities to suit the needs of your project.
diff --git a/docs/env-var-reference.md b/docs/env-var-reference.md
@@ -27,6 +27,7 @@ Used for specifying a GitHub Repository for CumulusCI to use when
 running in a CI environment.
 
 (cumulusci-system-certs)=
+
 ## `CUMULUSCI_SYSTEM_CERTS`
 
 If set to `True`, CumulusCI will configure the Python `requests` library
@@ -44,6 +45,7 @@ Contents of a JSON Web Token (JWT) used to [authenticate a GitHub
 app](https://developer.github.com/apps/building-github-apps/authenticating-with-github-apps/##authenticating-as-a-github-app).
 
 (github-token)=
+
 ## `GITHUB_TOKEN`
 
 A GitHub [personal access
diff --git a/docs/get-started.md b/docs/get-started.md
diff --git a/docs/headless.md b/docs/headless.md
diff --git a/docs/history.md b/docs/history.md
diff --git a/docs/robot/Keywords.html b/docs/robot/Keywords.html
diff --git a/docs/unpackaged.md b/docs/unpackaged.md

Original file line number	Diff line number	Diff line change
`@@ -1,4 +1,4 @@`
`1`		`-<!DOCTYPE html>`
	`1`	`+<!doctype html>`
`2`	`2`	`<html lang="en">`
`3`	`3`	`<head>`
`4`	`4`	`<title>Labels for testing</title>`