docs: format CHANGELOG.md with prettier (#181)

Author: cryptodev-2s

.github/workflows/build-test.yml

@@ -85,10 +85,10 @@ jobs:
       - run: yarn lint
       - name: Validate RC changelog
         if: ${{ startsWith(github.head_ref, 'release/') }}
-        run: yarn auto-changelog validate --rc
+        run: yarn auto-changelog validate --rc --prettier
       - name: Validate changelog
         if: ${{ !startsWith(github.head_ref, 'release/') }}
-        run: yarn auto-changelog validate
+        run: yarn auto-changelog validate --prettier
       - name: Require clean working directory
         shell: bash
         run: |

CHANGELOG.md

@@ -1,67 +1,90 @@
 # Changelog
+
 All notable changes to this project will be documented in this file.
 
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
 ## [Unreleased]
+
 ### Fixed
+
 - Improved error handling when opening browser fails due to System Events permissions or non-standard browser configurations ([#178](https://github.com/MetaMask/create-release-branch/pull/178))
   - Now provides clear manual URL instructions instead of failing with osascript errors
   - Handles both cases: when terminal lacks System Events permissions and when using alternative browsers like Brave
 
 ## [4.1.1]
+
 ### Fixed
+
 - Ask users to include peer dependents of a major-bumped package in the release, even they've had no changes ([#173](https://github.com/MetaMask/create-release-branch/pull/173))
 - UI: Include all peer dependents of a major-bumped package as available packages to release, even if they've had no changes ([#173](https://github.com/MetaMask/create-release-branch/pull/173))
 
 ## [4.1.0]
+
 ### Added
+
 - Add interactive web UI for selecting package versions to release ([#166](https://github.com/MetaMask/create-release-branch/pull/166))
   - Added `--interactive` (`-i`) flag to launch a web-based UI for easier version selection
   - Added `--port` option to configure the web server port (default: 3000)
 
 ### Changed
+
 - Refine breaking change dependent detection to only consider peer dependencies ([#170](https://github.com/MetaMask/create-release-branch/pull/170))
   - This change supports our policy of requiring packages with breaking changes to be released alongside their dependents
   - Regular dependencies are no longer included in this check
 - Allow `npm:name@version` dependency redirections in manifest ([#158](https://github.com/MetaMask/create-release-branch/pull/158))
 
 ## [4.0.0]
+
 ### Changed
+
 - **BREAKING:** Bump minimum Node.js version to `^18.18` ([#156](https://github.com/MetaMask/create-release-branch/pull/156))
 - **BREAKING:** Bump `@metamask/auto-changelog` to `^4.0.0` ([#156](https://github.com/MetaMask/create-release-branch/pull/156))
   - This requires `prettier@>=3.0.0`.
 
 ## [3.1.0]
+
 ### Changed
+
 - Allow `npm:name@version` dependency redirections in manifest ([#158](https://github.com/MetaMask/create-release-branch/pull/158)) ([#159](https://github.com/MetaMask/create-release-branch/pull/159))
 
 ## [3.0.1]
+
 ### Changed
+
 - Bump `@metamask/utils` to `^9.0.0` ([#150](https://github.com/MetaMask/create-release-branch/pull/150))
 
 ### Fixed
+
 - Correct Yarn constraint violations and update Yarn lockfile at the end of the release process ([#145](https://github.com/MetaMask/create-release-branch/pull/145))
   - This was previously a required step after running `create-release-branch`.
 
 ### Security
+
 - Enable MetaMask security code scanner ([#133](https://github.com/MetaMask/create-release-branch/pull/133))
 
 ## [3.0.0]
+
 ### Changed
+
 - **BREAKING:** Format changelogs using Prettier ([#100](https://github.com/MetaMask/create-release-branch/pull/100))
   - This is a breaking change since it changes the default formatting of the changelog in new release PRs. If you have a package script that runs `auto-changelog validate`, or you're calling `auto-changelog validate` in CI, you'll now need to pass the `--prettier` flag (see [example](https://github.com/MetaMask/metamask-module-template/pull/219)).
 
 ### Fixed
+
 - Restore support for monorepos that use `workspace:^` references for interdependencies ([#125](https://github.com/MetaMask/create-release-branch/pull/125))
 
 ## [2.0.1]
+
 ### Fixed
+
 - Move `@metamask/auto-changelog` from `devDependencies` to `dependencies` and pin to ~3.3.0 ([#122](https://github.com/MetaMask/create-release-branch/pull/122))
 
 ## [2.0.0]
+
 ### Changed
+
 - **BREAKING** Bump minimum Node version to 16 ([#114](https://github.com/MetaMask/create-release-branch/pull/114))
 - Reorder workflow to update changelogs first ([#109](https://github.com/MetaMask/create-release-branch/pull/109))
   - When you run this tool you can use the changelogs to decide which versions to include in your release.
@@ -70,22 +93,29 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - Soft-enforce major-bumped packages to be released along with their dependents ([#101](https://github.com/MetaMask/create-release-branch/pull/101))
   - If a new major version of a package A is being included in the release, and there are is a package B which depends on A but which is not also being released at the same time, then the tool will produce an error. This is to ensure that if a consumer is upgrading package A in a project and they also need to upgrade package B for compatibility reasons, they can.
 - Soft-enforce dependents to be released along with their dependencies ([#102](https://github.com/MetaMask/create-release-branch/pull/102))
-  - If package B depends on package A, and A has changed since its last release, and B is being included in the release but not A, then the tool will produce an error. This is to ensure that if B has been changed to rely on a new feature that was added to A, it doesn't break when it is used in a project (since that feature is present in development but has  not been published).
+  - If package B depends on package A, and A has changed since its last release, and B is being included in the release but not A, then the tool will produce an error. This is to ensure that if B has been changed to rely on a new feature that was added to A, it doesn't break when it is used in a project (since that feature is present in development but has not been published).
 
 ## [1.1.0]
+
 ### Added
+
 - Add support for nested workspaces ([#84](https://github.com/MetaMask/create-release-branch/pull/84))
 
 ### Changed
+
 - Add `.yml` extension to `RELEASE_SPEC` file ([#83](https://github.com/MetaMask/create-release-branch/pull/83))
 
 ## [1.0.1]
+
 ### Fixed
+
 - Update changelogs correctly for monorepo packages ([#50](https://github.com/MetaMask/create-release-branch/pull/50))
   - The changelog update step was encountering an error when used for a monorepo package release that had already been released at least once. Related to this, the changelog was being updated with the wrong tag links. Both problems should now be resolved.
 
 ## [1.0.0]
+
 ### Added
+
 - Initial release
   - In this first release, this tool only supports monorepos with an independent versioning scheme. We will add support for other kinds of projects in future releases.
   - You can learn more on how to use this tool by reading the [documentation](docs/).

README.md

@@ -2,7 +2,7 @@
 
 This is an interactive command-line tool that automates steps involved in preparing a new release of a project. These steps include updating versions of one or more desired packages, adding a new section to the packages' changelogs to include changes since the previous release, and then creating a new branch from which a pull request can be submitted for review before the release goes live.
 
-> **Note**  
+> **Note**
 > At the moment, this tool only supports monorepos that use an independent versioning strategy. Support for other types of projects is planned in a future release.
 
 ## Installation
@@ -61,7 +61,7 @@ The project follows the same release process as the other libraries in the MetaM
    - Generally any changes that don't affect consumers of the package (e.g. lockfile changes or development environment changes) are omitted. Exceptions may be made for changes that might be of interest despite not having an effect upon the published package (e.g. major test improvements, security improvements, improved documentation, etc.).
    - Try to explain each change in terms that users of the package would understand (e.g. avoid referencing internal variables/concepts).
    - Consolidate related changes into one change entry if it makes it easier to explain.
-   - Run `yarn auto-changelog validate --rc` to check that the changelog is correctly formatted.
+   - Run `yarn auto-changelog validate --rc --prettier` to check that the changelog is correctly formatted.
 
 5. Review and QA the release.
 

docs/changelog.md

@@ -12,4 +12,4 @@ After running this tool, you'll want to follow a few steps:
    - **Consolidation.** A changelog entry represents a complete unit of work, and some work may be split across multiple commits. In this case, you can combine multiple entries together, listing multiple PRs instead of just one.
    - **Omission.** Some changes do not affect end users of the project (e.g. lockfile changes, development environment changes, etc.). In these cases, you may remove these entries entirely. Exceptions may be made for changes that might be of interest despite not having an effect upon the published package (e.g. major test improvements, security improvements, improved documentation, etc.).
 
-3. Once you're made your edits, make sure to run `yarn auto-changelog validate --rc` to check that the changelog is correctly formatted.
+3. Once you're made your edits, make sure to run `yarn auto-changelog validate --rc --prettier` to check that the changelog is correctly formatted.