ci: remove husky, add semantic-pull-request (#29)

- Split runs for PR vs main.
- Minor task touchups
- Get rid of Husky and commitlint.
- Enable `semantic-pull-requests` GH application for linting of PR title / squash and merge workflow. We no longer need commitlint. Closes #24 
- Document best practices for PR and actual release. Closes #21

.github/workflows/publish.yaml

@@ -1,35 +1,54 @@
 name: Publish
-on: [ push ]
+
+on:
+  push:
+    branches:
+      - main
+  pull_request:
+    branches:
+      - main
+
 jobs:
-  build:
-    name: Build
-    runs-on: ubuntu-latest
+  publish:
+    name: Publish
+
+    runs-on: ${{ matrix.os }}
+
+    strategy:
+      matrix:
+        os: [ubuntu-latest]
+        node-version: [14.x]
+
     steps:
-      -
-        name: Checkout code
+      - name: Checkout code
         uses: actions/checkout@v2
-      -
-        name: Use Node.js 14
+
+      - name: Use Node.js ${{ matrix.node-version }}
         uses: actions/setup-node@v1
         with:
-          node-version: 14
-          registry-url: https://registry.npmjs.org/
-      -
-        run: npm install -g yarn
-      -
-        run: yarn install --frozen-lockfile
-      -
+          node-version: ${{ matrix.node-version }}
+
+      - name: Install
+        run: yarn install --frozen-lockfile --non-interactive
+
+      - name: Build
         run: yarn run build
-      -
+
+      - name: Add npm token
         run: echo '//registry.npmjs.org/:_authToken=${NPM_TOKEN}' > .npmrc
-      -
+
+      # Only do a dry-run in Pull Request
+      - name: Publish (dry-run)
+        if: ${{ github.ref != 'refs/heads/main' }}
         run: yarn run semantic-release --dry-run
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
-      -
-        run: yarn run semantic-release
+
+      # Release release in merge to default branch
+      - name: Publish
         if: ${{ github.ref == 'refs/heads/main' }}
+        run: yarn run semantic-release
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

README.md

@@ -1,33 +1,36 @@
-# dogs
+dogs 🐕
+======
+
 Formidable Dogs
 
 ## Contributing
+
 This repository is configured using [semantic-release](https://github.com/semantic-release/semantic-release) which automates the whole package release workflow including: determining the next version number, generating the release notes and publishing the package.
 
-What does this mean for contributors? Your commit messages will be linted using [commitlint](https://github.com/conventional-changelog/commitlint) and must adhere to the [conventional commit format](https://www.conventionalcommits.org/en/v1.0.0/).
+What does this mean for contributors? It means we need a merge commit that follows the [conventional commit format](https://www.conventionalcommits.org/en/v1.0.0/). There are lots of ways to do `semantic-release` and commit vetting, but here's how _we_ do it in this repo:
+
+1. Our target for `semantic-release` is a "Squash and merge" GitHub pull request merge. We aim to have the _final_ commit meet the conventional commit format.
+    * **Note**: This means that along the way to that final merge commit, it doesn't matter how you commit. We don't do pre-commit hooks, nor lint individual commits in a pull request. All we check is the final merge commit to make sure it's all good.
+2. This means that the thing you need to check is the **pull request title** which is what will be used in the squash and merge commit to trigger `semantic release`. We use [semantic-pull-requests](https://github.com/zeke/semantic-pull-requests) to make sure that our PRs have a title meet the eventual format needed. And no worries about changes along the way! You just need to get the PR title in appropriate shape by the time you want to merge.
 
 There are very precise rules over how git commit messages can be formatted. This leads to **more
 readable messages** that are easy to follow when looking through the **project history**. Also,
 the git commit messages are used to **generate the AngularJS change log**.
 
-### Anatomy of a commit
-Each commit message consists of a **header**, a **body** and a **footer**.  The header has a special
-format that includes a **type**, a **scope** and a **subject**:
+### Anatomy of a pull request title
+
+The `semantic-pull-requests` bot goes for the minimal `semantic-release` information to make doing versioning as easy as possible. For how _we_ do it in this project, you just need to focus on the PR title (that must be preserved in the squash and merge commit).
+
+The pull request title has a special format that should include a **type**, a **scope** and a **subject**:
 
 ```
 <type>(<scope>): <subject>
-<BLANK LINE>
-<body>
-<BLANK LINE>
-<footer>
 ```
 
-The **header** is mandatory and the **scope** of the header is optional.
-
-Any line of the commit message cannot be longer than 100 characters! This allows the message to be easier
-to read on GitHub as well as in various git tools.
+The **scope** of the header is optional.
 
 ### What type of commits trigger a release?
+
 Type must be one of `[build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test]`.
 - The types `build|ci|revert` are [undocumented](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#type) but exist in [code](https://github.com/conventional-changelog/commitlint/blob/5fd27fdcd2d88435257f888d832fc19c5bbc037f/%40commitlint/config-conventional/index.test.js#L39).
 
@@ -43,14 +46,16 @@ Type must be one of `[build, chore, ci, docs, feat, fix, perf, refactor, revert,
 | `test`       | Changes to the test process                         | N/A            |
 
 ### What about major version bumps?
-Major version bumps are considered **breaking changes** for `semantic-release` and are triggered intentionally. The footer should contain any information about major changes  breaking changes and is also the place to reference GitHub issues that this commit closes.
 
-**Breaking changes** should start with the word `BREAKING CHANGE:` with two newlines. The rest of the commit message is then used for this.
+Major version bumps are considered **breaking changes** for `semantic-release` and are triggered intentionally.
 
-#### Example
-```
-perf: removed pictures from published package
+**Breaking changes** should start with a `!` after the commit type. This changes a usual N/A version impact of something like `refactor` or `fix` to a breaking change with `refactor!` or `fix!`.
 
-BREAKING CHANGE: The dog .jpg files have been removed from the package. 
-This decreases the package size from megabytes to kilobytes.
-```
+#### Examples
+
+Any of the following PR titles should work for the appropriate release:
+
+* `perf: removed pictures from published package`: Patch
+* `refactor(utils): change internal file utils`: N/A. Add an ad-hoc scope.
+* `refactor: change internal function`: N/A
+* `refactor!: remove dog .jpg files`: Major

package.json

@@ -14,24 +14,11 @@
   "typings": "dist/index.d.ts",
   "dependencies": {},
   "devDependencies": {
-    "@commitlint/cli": "^11.0.0",
-    "@commitlint/config-conventional": "^11.0.0",
     "@semantic-release/git": "^9.0.0",
-    "husky": "^4.3.0",
     "rimraf": "^3.0.2",
     "semantic-release": "^17.2.4",
     "typescript": "^4.0.3"
   },
-  "commitlint": {
-    "extends": [
-      "@commitlint/config-conventional"
-    ]
-  },
-  "husky": {
-    "hooks": {
-      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
-    }
-  },
   "release": {
     "branches": [
       "main"