Rebuild for speed and simplicity

.github/ISSUE_TEMPLATE/bug_report.md

@@ -2,11 +2,13 @@
 name: Bug report
 about: Create a report to help us improve
 ---
+
 **Describe the bug**
 A clear and concise description of what the bug is.
 
 **To Reproduce**
 Steps to reproduce the behavior:
+
 1. Go to '...'
 2. Click on '....'
 3. Scroll down to '....'
@@ -19,15 +21,17 @@ A clear and concise description of what you expected to happen.
 If applicable, add screenshots to help explain your problem.
 
 **Desktop (please complete the following information):**
- - OS: [e.g. iOS]
- - Browser [e.g. chrome, safari]
- - Version [e.g. 22]
+
+- OS: [e.g. iOS]
+- Browser [e.g. chrome, safari]
+- Version [e.g. 22]
 
 **Smartphone (please complete the following information):**
- - Device: [e.g. iPhone6]
- - OS: [e.g. iOS8.1]
- - Browser [e.g. stock browser, safari]
- - Version [e.g. 22]
+
+- Device: [e.g. iPhone6]
+- OS: [e.g. iOS8.1]
+- Browser [e.g. stock browser, safari]
+- Version [e.g. 22]
 
 **Additional context**
-Add any other context about the problem here.
+Add any other context about the problem here.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -2,6 +2,7 @@
 name: Feature request
 about: Suggest an idea for this project
 ---
+
 **Is your feature request related to a problem? Please describe.**
 A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
 
@@ -12,4 +13,4 @@ A clear and concise description of what you want to happen.
 A clear and concise description of any alternative solutions or features you've considered.
 
 **Additional context**
-Add any other context or screenshots about the feature request here.
+Add any other context or screenshots about the feature request here.

.github/PULL_REQUEST_TEMPLATE.md

@@ -18,4 +18,4 @@
 
 - [ ] My change is documented
 - [ ] My change is tested
-- [ ] My change is in the Changelog
+- [ ] My change is in the Changelog

.github/workflows/compile.yml

@@ -3,10 +3,9 @@ name: Compile source code
 on:
   workflow_dispatch:
   pull_request:
-    branches: [ main ]
+    branches: [main]
 
 jobs:
-
   compile:
     runs-on: ubuntu-latest
     steps:
@@ -23,4 +22,4 @@ jobs:
       - name: Compile source code
         run: |
           npm ci
-          npm run compile
+          npm run compile

.github/workflows/quality.yml

@@ -3,10 +3,9 @@ name: Enforce code quality
 on:
   workflow_dispatch:
   pull_request:
-    branches: [ main ]
+    branches: [main]
 
 jobs:
-
   lint:
     runs-on: ubuntu-latest
     steps:

.nvmrc

@@ -1 +1 @@
-v19.3.0
+v21.5.0

CHANGELOG.md

@@ -1,83 +1,101 @@
 # 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](https://github.com/paulshryock/release-bump/compare/HEAD..v2.2.1)
+## [Unreleased]
 
 ### Added
 
 ### Changed
-- [Breaking changes] Rewrite core API and CLI.
+
+- Bump changelog and get on with it.
+- Bump docblock comments via git and sed.
 
 ### Deprecated
 
 ### Removed
 
+- All command line args.
+
 ### Fixed
 
 ### Security
 
-## [2.2.1](https://github.com/paulshryock/release-bump/releases/tag/v2.2.1) - 2021/07/29
+## [2.2.1] - 2021/07/29
 
 ### Changed
+
 - Update `file` util methods.
 - Update test coverage.
 
-## [2.2.0](https://github.com/paulshryock/release-bump/releases/tag/v2.2.0) - 2021/07/28
+## [2.2.0] - 2021/07/28
 
 ### Added
+
 - Add unit tests. [#22]
 - Add `type` util methods.
 - Add `quiet` CLI flag.
 - Add linting. [#26]
 
 ### Changed
+
 - Update `file` util methods.
 
-## [2.1.0](https://github.com/paulshryock/release-bump/releases/tag/v2.1.0) - 2021/07/21
+## [2.1.0] - 2021/07/21
 
 ### Added
+
 - Add prefix configuration.
 
-## [2.0.0](https://github.com/paulshryock/release-bump/releases/tag/v2.0.0) - 2021/07/20
+## [2.0.0] - 2021/07/20
 
 ### Added
+
 - Bump WordPress plugin.
 
 ### Changed
+
 - Rewrite classes.
 
 ### Removed
+
 - Remove configuration.
 
-## [1.3.0](https://github.com/paulshryock/release-bump/releases/tag/v1.3.0) - 5/20/2021
+## [1.3.0] - 5/20/2021
 
 ### Added
+
 - Bump WordPress theme.
 
-## [1.2.1](https://github.com/paulshryock/release-bump/releases/tag/v1.2.1) - 4/5/2021
+## [1.2.1] - 4/5/2021
 
 ### Fixed
+
 - Fix release tags typo. [#12]
 
-## [1.2.0](https://github.com/paulshryock/release-bump/releases/tag/v1.2.0) - 4/5/2021
+## [1.2.0] - 4/5/2021
 
 ### Added
+
 - Get package version from CLI. [#7]
 - Get package help documentation from CLI.
 
 ### Changed
+
 - Better logging.
 - Cancel Changelog bump if file does not exist.
 
-## [1.1.0](https://github.com/paulshryock/release-bump/releases/tag/v1.1.0) - 4/2/2021
+## [1.1.0] - 4/2/2021
 
 ### Added
+
 - Add CLI flag configuration. [#4]
 
-## [1.0.0](https://github.com/paulshryock/release-bump/releases/tag/v1.0.0) - 3/30/2021
+## [1.0.0] - 3/30/2021
 
 ### Added
-- Bump Changelog.
+
+- Bump Changelog.

CODE_OF_CONDUCT.md

@@ -17,23 +17,23 @@ diverse, inclusive, and healthy community.
 Examples of behavior that contributes to a positive environment for our
 community include:
 
-* Demonstrating empathy and kindness toward other people
-* Being respectful of differing opinions, viewpoints, and experiences
-* Giving and gracefully accepting constructive feedback
-* Accepting responsibility and apologizing to those affected by our mistakes,
+- Demonstrating empathy and kindness toward other people
+- Being respectful of differing opinions, viewpoints, and experiences
+- Giving and gracefully accepting constructive feedback
+- Accepting responsibility and apologizing to those affected by our mistakes,
   and learning from the experience
-* Focusing on what is best not just for us as individuals, but for the overall
+- Focusing on what is best not just for us as individuals, but for the overall
   community
 
 Examples of unacceptable behavior include:
 
-* The use of sexualized language or imagery, and sexual attention or advances of
+- The use of sexualized language or imagery, and sexual attention or advances of
   any kind
-* Trolling, insulting or derogatory comments, and personal or political attacks
-* Public or private harassment
-* Publishing others' private information, such as a physical or email address,
+- Trolling, insulting or derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or email address,
   without their explicit permission
-* Other conduct which could reasonably be considered inappropriate in a
+- Other conduct which could reasonably be considered inappropriate in a
   professional setting
 
 ## Enforcement Responsibilities

CONTRIBUTING.md

@@ -4,12 +4,14 @@
 - [Dependencies](#dependencies)
 
 - [Git](#git)
+
   - [Branches](#branches)
   - [Commits](#commits)
   - [Pull requests](#pull-requests)
   - [Tags](#tags)
 
 - [Code quality](#code-quality)
+
   - [During development](#during-development)
   - [Skipping code quality checks](#skipping-code-quality-checks)
 
@@ -47,7 +49,7 @@ This repository uses [Trunk Based Development](https://trunkbaseddevelopment.com
 
 3. [Write better commit messages](https://www.freecodecamp.org/news/how-to-write-better-git-commit-messages/)
 
-> By writing good commits, you are simply future-proofing yourself. You could save yourself and/or coworkers hours of digging around while troubleshooting by providing that helpful description. The extra time it takes to write a thoughtful commit message as a letter to your potential future self is extremely worthwhile. On large scale projects, documentation is imperative for maintenance. 
+> By writing good commits, you are simply future-proofing yourself. You could save yourself and/or coworkers hours of digging around while troubleshooting by providing that helpful description. The extra time it takes to write a thoughtful commit message as a letter to your potential future self is extremely worthwhile. On large scale projects, documentation is imperative for maintenance.
 
 4. [Format your commits](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)
 
@@ -62,11 +64,11 @@ This repository uses [Trunk Based Development](https://trunkbaseddevelopment.com
 
 Never commit directly to the `main` branch. Work on a short-lived feature branch and then create a pull request against `main`. When you push code to the remote, CI will automatically run code quality checks and ensure that your source code compiles. These checks must pass before merging your PR, and you must have an approval from another engineer.
 
-- *Fast forward (`rebase` and `merge`):* Use [linear history](https://devblog.nestoria.com/post/98892582763/maintaining-a-consistent-linear-history-for-git).
+- _Fast forward (`rebase` and `merge`):_ Use [linear history](https://devblog.nestoria.com/post/98892582763/maintaining-a-consistent-linear-history-for-git).
 
-- *Squash:* If you have multiple or messy commits which should be combined into one on the `main` branch, squash your pull request with a descriptive commit message.
+- _Squash:_ If you have multiple or messy commits which should be combined into one on the `main` branch, squash your pull request with a descriptive commit message.
 
-- *Merge commit (`merge --no-ff`):* [You probably don't need this](https://dev.to/bladesensei/avoid-messy-git-history-3g26).
+- _Merge commit (`merge --no-ff`):_ [You probably don't need this](https://dev.to/bladesensei/avoid-messy-git-history-3g26).
 
 ### Tags
 
@@ -93,23 +95,24 @@ We use EditorConfig and Prettier with some configuration.
 
 1. **Line length set to 80 characters** (with soft limit at 120 characters and exceptions for data files)
 
-    > Shorter lines are more comfortable to read than longer lines. As line length increases, your eye has to travel farther from the end of one line to the beginning of the next, making it harder to track your progress vertically. Aim for an average line length of 45–90 characters, including spaces.
-    >
-    > -- [Butterick's Practical Typography](https://practicaltypography.com/line-length.html)
+   > Shorter lines are more comfortable to read than longer lines. As line length increases, your eye has to travel farther from the end of one line to the beginning of the next, making it harder to track your progress vertically. Aim for an average line length of 45–90 characters, including spaces.
+   >
+   > -- [Butterick's Practical Typography](https://practicaltypography.com/line-length.html)
 
 2. **Tabs for indenting** (with exceptions for white space-sensitive data files)
-  - [Tabs are more accessible](https://alexandersandberg.com/articles/default-to-tabs-instead-of-spaces-for-an-accessible-first-environment/)
-  - [Tabs are customizable](https://garrit.xyz/posts/2022-06-29-the-only-true-answer-to-tabs-vs-spaces) (use whatever tab size you like on your computer)
+
+- [Tabs are more accessible](https://alexandersandberg.com/articles/default-to-tabs-instead-of-spaces-for-an-accessible-first-environment/)
+- [Tabs are customizable](https://garrit.xyz/posts/2022-06-29-the-only-true-answer-to-tabs-vs-spaces) (use whatever tab size you like on your computer)
 
 3. Insert final newline at end of file: [Text files end in a newline](https://unix.stackexchange.com/a/18789)
 
 4. In function and method declarations, the opening brace SHOULD stay on the same line
 
-    ```javascript
-    function hello() {
-      return 'hello';
-    }
-    ```
+   ```javascript
+   function hello() {
+     return 'hello'
+   }
+   ```
 
 #### EditorConfig
 
@@ -169,7 +172,7 @@ To release code under a prerelease tag before a formal release is ready, use `np
 ##### Prerelease ID's
 
 | ID        | Feature status                          | Bug status     | Testing status                     |
-| :---      | :---                                    | :---           | :---                               |
+| :-------- | :-------------------------------------- | :------------- | :--------------------------------- |
 | `nightly` | May not have any complete features yet. | May have bugs. | Not ready for testing.             |
 | `alpha`   | At least 1 feature is complete.         | May have bugs. | Ready for developer testing.       |
 | `beta`    | All features are complete.              | May have bugs. | Ready for QA testing.              |