@procore/globalization-toolkit 1.7.1 → 1.8.1

package/README.md

@@ -13,35 +13,43 @@ $ npm i --save @procore/globalization-toolkit
 ```
 
 # Developing
+
 Install dependencies:
+
 ```sh
 $ npm install
 ```
 
 Prepare project:
+
 ```sh
 $ npm run prepare
 ```
 
 Compile Typescript:
+
 ```sh
 $ npm run build
 ```
+
 (Delete build `npm run clean`)
 
 ## Testing
+
 ```sh
 $ npm run test
 ```
 
 If adding a new supported export (or removing one in a breaking change), update the snapshot test output and commit the change.
+
 ```sh
-$ npm run test -u
+$ npm run test -- -u
 ```
 
 To check formatting run `npm run lint:check` and `npm run format:check`.
 
 ## Committing Changes
+
 Our repo follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/)
 and [Semantic Versioning](https://semver.org/) specifications.
 The Conventional Commit format is used to map commits to the next Semantic Version published to `NPM`,
@@ -56,12 +64,15 @@ Generally, commits should be in the format:
 
 [optional footer(s)]
 ```
+
 We use the command line tool [`commitizen`](https://github.com/commitizen/cz-cli#using-the-command-line-tool) to help walk you through generating a Conventional Commit.
 
 **To invoke this tool run:**
+
 ```sh
 $ npm run cm
 ```
+
 (Optional: [run commitizen on `git commit`](https://github.com/commitizen/cz-cli#optional-running-commitizen-on-git-commit))
 
 #### Certain commits are analyzed and mapped to versioning as follows:
@@ -72,25 +83,25 @@ $ npm run cm
 
 - `PATCH` release for commit types `fix` or `perf`.
 
-
 - No release is triggered for all other commit types.
   And commits that do not match any format rules or have `no-release` as the scope
   will not trigger a release.
 
 Additionally, `releaseRules` are specified in `package.json` for specific commits:
+
 - `build(deps-dev):` does not trigger a release (development dependency changes, typically version bumps by `dependabot`).
 - `build(deps):` triggers a `PATCH` release.
 
-*Details about how commit types are mapped to versioning can be found in the [commit-analyzer documentation](https://github.com/semantic-release/commit-analyzer/#default-rules-matching).*
-
+_Details about how commit types are mapped to versioning can be found in the [commit-analyzer documentation](https://github.com/semantic-release/commit-analyzer/#default-rules-matching)._
 
 # Publishing
+
 Merges to `main` will trigger the `publish` workflow in CircleCi.
 We use [`semantic-release`](https://semantic-release.gitbook.io/semantic-release/) to manage releases and publishing to `NPM`.
 Semantic Release relies on the project's commit history
 to create release notes and determine the next version.
 
-
 ### Release Notes:
+
 The `<description>` for commits selected for publishing are added to the release notes
-and can be found in the **Releases** section of Github. 
+and can be found in the **Releases** section of Github.