style: reformat stuff that must have been formatted before 47d2dad

Author: jrolfs

CHANGELOG.md

@@ -1,4 +1,5 @@
 # CHANGELOG
 
-The changelog is automatically updated using [semantic-release](https://github.com/semantic-release/semantic-release).
-You can see it on the [releases page](../../releases).
+The changelog is automatically updated using
+[semantic-release](https://github.com/semantic-release/semantic-release). You
+can see it on the [releases page](../../releases).

CONTRIBUTING.md

@@ -2,8 +2,8 @@
 
 Thanks for being willing to contribute!
 
-**Working on your first Pull Request?** You can learn how from this _free_ series
-[How to Contribute to an Open Source Project on GitHub][egghead]
+**Working on your first Pull Request?** You can learn how from this _free_
+series [How to Contribute to an Open Source Project on GitHub][egghead]
 
 ## Project setup
 
@@ -21,24 +21,23 @@ Thanks for being willing to contribute!
 > git branch --set-upstream-to=upstream/master master
 > ```
 >
-> This will add the original repository as a "remote" called "upstream,"
-> Then fetch the git information from that remote, then set your local `master`
-> branch to use the upstream master branch whenever you run `git pull`.
-> Then you can make all of your pull request branches based on this `master`
-> branch. Whenever you want to update your version of `master`, do a regular
-> `git pull`.
+> This will add the original repository as a "remote" called "upstream," Then
+> fetch the git information from that remote, then set your local `master`
+> branch to use the upstream master branch whenever you run `git pull`. Then you
+> can make all of your pull request branches based on this `master` branch.
+> Whenever you want to update your version of `master`, do a regular `git pull`.
 
 ## Committing and Pushing changes
 
 This project uses [`semantic-release`][semantic-release] to do automatic
-releases and generate a changelog based on the commit history. So we follow
-[a convention][convention] for commit messages. You don't have to follow this
+releases and generate a changelog based on the commit history. So we follow [a
+convention][convention] for commit messages. You don't have to follow this
 convention if you don't want to. Just know that when we merge your commit, we'll
 probably use "Squash and Merge" so we can change the commit message :)
 
 Please make sure to run the tests before you commit your changes. You can run
-`npm run test:update` which will update any snapshots that need updating.
-Make sure to include those changes (if they exist) in your commit.
+`npm run test:update` which will update any snapshots that need updating. Make
+sure to include those changes (if they exist) in your commit.
 
 ### opt in/out of git hooks
 
@@ -53,10 +52,10 @@ pre-commit
 ```
 
 One of the things that the git hooks does is automatically format the files you
-change. It does this by reformating the entire file and running `git add` on
-the file after. This breaks workflows where you're trying to commit portions of
-the file only. You can always run your commit with `--no-verify`, but if this
-is a bummer to your workflow, you can add an `.opt-out` file with the contents:
+change. It does this by reformating the entire file and running `git add` on the
+file after. This breaks workflows where you're trying to commit portions of the
+file only. You can always run your commit with `--no-verify`, but if this is a
+bummer to your workflow, you can add an `.opt-out` file with the contents:
 
 ```
 autoformat
@@ -69,7 +68,9 @@ Please checkout the [the open issues][issues]
 Also, please watch the repo and respond to questions/bug reports/feature
 requests! Thanks!
 
-[egghead]: https://egghead.io/series/how-to-contribute-to-an-open-source-project-on-github
+[egghead]:
+  https://egghead.io/series/how-to-contribute-to-an-open-source-project-on-github
 [semantic-release]: https://npmjs.com/package/semantic-release
-[convention]: https://github.com/conventional-changelog/conventional-changelog-angular/blob/ed32559941719a130bb0327f886d6a32a8cbc2ba/convention.md
+[convention]:
+  https://github.com/conventional-changelog/conventional-changelog-angular/blob/ed32559941719a130bb0327f886d6a32a8cbc2ba/convention.md
 [issues]: https://github.com/hoverinc/hover-javascript/issues

README.md

@@ -85,15 +85,15 @@ Or, for `babel`, a `.babelrc` with:
 Or, for `jest`:
 
 ```javascript
-const { jest: jestConfig } = require('@hover/javascript/jest');
+const {jest: jestConfig} = require('@hover/javascript/jest')
 module.exports = Object.assign(jestConfig, {
   // your overrides here
 
   // for test written in Typescript, add:
   transform: {
     '\\.(ts|tsx)$': '<rootDir>/node_modules/ts-jest/preprocessor.js',
   },
-});
+})
 ```
 
 > Note: `hover-scripts` intentionally does not merge things for you when you

other/CODE_OF_CONDUCT.md

@@ -20,9 +20,9 @@
 In the interest of fostering an open and welcoming environment, we as
 contributors and maintainers pledge to making participation in our project and
 our community a harassment-free experience for everyone, regardless of age, body
-size, disability, ethnicity, gender identity and expression, level of experience,
-nationality, personal appearance, race, religion, or sexual identity and
-orientation.
+size, disability, ethnicity, gender identity and expression, level of
+experience, nationality, personal appearance, race, religion, or sexual identity
+and orientation.
 
 ## Our Standards
 
@@ -52,11 +52,11 @@ Project maintainers are responsible for clarifying the standards of acceptable
 behavior and are expected to take appropriate and fair corrective action in
 response to any instances of unacceptable behavior.
 
-Project maintainers have the right and responsibility to remove, edit, or
-reject comments, commits, code, wiki edits, issues, and other contributions
-that are not aligned to this Code of Conduct, or to ban temporarily or
-permanently any contributor for other behaviors that they deem inappropriate,
-threatening, offensive, or harmful.
+Project maintainers have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, or to ban temporarily or permanently any
+contributor for other behaviors that they deem inappropriate, threatening,
+offensive, or harmful.
 
 ## Scope
 
@@ -73,17 +73,18 @@ Instances of abusive, harassing, or otherwise unacceptable behavior may be
 reported by contacting the project team at kent+coc@doddsfamily.us. All
 complaints will be reviewed and investigated and will result in a response that
 is deemed necessary and appropriate to the circumstances. The project team is
-obligated to maintain confidentiality with regard to the reporter of an incident.
-Further details of specific enforcement policies may be posted separately.
+obligated to maintain confidentiality with regard to the reporter of an
+incident. Further details of specific enforcement policies may be posted
+separately.
 
 Project maintainers who do not follow or enforce the Code of Conduct in good
 faith may face temporary or permanent repercussions as determined by other
 members of the project's leadership.
 
 ## Attribution
 
-This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
-available at [http://contributor-covenant.org/version/1/4][version]
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
 
 [homepage]: http://contributor-covenant.org
 [version]: http://contributor-covenant.org/version/1/4/

other/MAINTAINING.md

@@ -18,60 +18,67 @@ This is documentation for maintainers of this project.
 
 ## Code of Conduct
 
-Please review, understand, and be an example of it. Violations of the code of conduct are
-taken seriously, even (especially) for maintainers.
+Please review, understand, and be an example of it. Violations of the code of
+conduct are taken seriously, even (especially) for maintainers.
 
 ## Issues
 
-We want to support and build the community. We do that best by helping people learn to solve
-their own problems. We have an issue template and hopefully most folks follow it. If it's
-not clear what the issue is, invite them to create a minimal reproduction of what they're trying
-to accomplish or the bug they think they've found.
+We want to support and build the community. We do that best by helping people
+learn to solve their own problems. We have an issue template and hopefully most
+folks follow it. If it's not clear what the issue is, invite them to create a
+minimal reproduction of what they're trying to accomplish or the bug they think
+they've found.
 
 Once it's determined that a code change is necessary, point people to
-[makeapullrequest.com](http://makeapullrequest.com) and invite them to make a pull request.
-If they're the one who needs the feature, they're the one who can build it. If they need
-some hand holding and you have time to lend a hand, please do so. It's an investment into
-another human being, and an investment into a potential maintainer.
+[makeapullrequest.com](http://makeapullrequest.com) and invite them to make a
+pull request. If they're the one who needs the feature, they're the one who can
+build it. If they need some hand holding and you have time to lend a hand,
+please do so. It's an investment into another human being, and an investment
+into a potential maintainer.
 
-Remember that this is open source, so the code is not yours, it's ours. If someone needs a change
-in the codebase, you don't have to make it happen yourself. Commit as much time to the project
-as you want/need to. Nobody can ask any more of you than that.
+Remember that this is open source, so the code is not yours, it's ours. If
+someone needs a change in the codebase, you don't have to make it happen
+yourself. Commit as much time to the project as you want/need to. Nobody can ask
+any more of you than that.
 
 ## Pull Requests
 
-As a maintainer, you're fine to make your branches on the main repo or on your own fork. Either
-way is fine.
+As a maintainer, you're fine to make your branches on the main repo or on your
+own fork. Either way is fine.
 
-When we receive a pull request, a travis build is kicked off automatically (see the `.travis.yml`
-for what runs in the travis build). We avoid merging anything that breaks the travis build.
+When we receive a pull request, a travis build is kicked off automatically (see
+the `.travis.yml` for what runs in the travis build). We avoid merging anything
+that breaks the travis build.
 
-Please review PRs and focus on the code rather than the individual. You never know when this is
-someone's first ever PR and we want their experience to be as positive as possible, so be
-uplifting and constructive.
+Please review PRs and focus on the code rather than the individual. You never
+know when this is someone's first ever PR and we want their experience to be as
+positive as possible, so be uplifting and constructive.
 
 When you merge the pull request, 99% of the time you should use the
-[Squash and merge](https://help.github.com/articles/merging-a-pull-request/) feature. This keeps
-our git history clean, but more importantly, this allows us to make any necessary changes to the
-commit message so we release what we want to release. See the next section on Releases for more
-about that.
+[Squash and merge](https://help.github.com/articles/merging-a-pull-request/)
+feature. This keeps our git history clean, but more importantly, this allows us
+to make any necessary changes to the commit message so we release what we want
+to release. See the next section on Releases for more about that.
 
 ## Release
 
-Our releases are automatic. They happen whenever code lands into `master`. A travis build gets
-kicked off and if it's successful, a tool called
-[`semantic-release`](https://github.com/semantic-release/semantic-release) is used to
-automatically publish a new release to npm as well as a changelog to GitHub. It is only able to
-determine the version and whether a release is necessary by the git commit messages. With this
-in mind, **please brush up on [the commit message convention][commit] which drives our releases.**
+Our releases are automatic. They happen whenever code lands into `master`. A
+travis build gets kicked off and if it's successful, a tool called
+[`semantic-release`](https://github.com/semantic-release/semantic-release) is
+used to automatically publish a new release to npm as well as a changelog to
+GitHub. It is only able to determine the version and whether a release is
+necessary by the git commit messages. With this in mind, **please brush up on
+[the commit message convention][commit] which drives our releases.**
 
-> One important note about this: Please make sure that commit messages do NOT contain the words
-> "BREAKING CHANGE" in them unless we want to push a major version. I've been burned by this
-> more than once where someone will include "BREAKING CHANGE: None" and it will end up releasing
-> a new major version. Not a huge deal honestly, but kind of annoying...
+> One important note about this: Please make sure that commit messages do NOT
+> contain the words "BREAKING CHANGE" in them unless we want to push a major
+> version. I've been burned by this more than once where someone will include
+> "BREAKING CHANGE: None" and it will end up releasing a new major version. Not
+> a huge deal honestly, but kind of annoying...
 
 ## Thanks!
 
 Thank you so much for helping to maintain this project!
 
-[commit]: https://github.com/conventional-changelog-archived-repos/conventional-changelog-angular/blob/ed32559941719a130bb0327f886d6a32a8cbc2ba/convention.md
+[commit]:
+  https://github.com/conventional-changelog-archived-repos/conventional-changelog-angular/blob/ed32559941719a130bb0327f886d6a32a8cbc2ba/convention.md

other/manual-releases.md

@@ -6,10 +6,11 @@
 
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
 
-This project has an automated release set up. So things are only released when there are
-useful changes in the code that justify a release. But sometimes things get messed up one way or another
-and we need to trigger the release ourselves. When this happens, simply bump the number below and commit
-that with the following commit message based on your needs:
+This project has an automated release set up. So things are only released when
+there are useful changes in the code that justify a release. But sometimes
+things get messed up one way or another and we need to trigger the release
+ourselves. When this happens, simply bump the number below and commit that with
+the following commit message based on your needs:
 
 **Major**
 

src/__tests__/index.js

@@ -1,58 +1,58 @@
-import path from 'path';
-import slash from 'slash';
-import cases from 'jest-in-case';
-import { unquoteSerializer } from '../scripts/__tests__/helpers/serializers';
+import path from 'path'
+import slash from 'slash'
+import cases from 'jest-in-case'
+import {unquoteSerializer} from '../scripts/__tests__/helpers/serializers'
 
-const projectRoot = path.join(__dirname, '../../');
+const projectRoot = path.join(__dirname, '../../')
 
-expect.addSnapshotSerializer(unquoteSerializer);
+expect.addSnapshotSerializer(unquoteSerializer)
 expect.addSnapshotSerializer({
   print: val => slash(val.replace(projectRoot, '<PROJECT_ROOT>/')),
   test: val => typeof val === 'string' && val.includes(projectRoot),
-});
+})
 
 cases(
   'format',
-  ({ snapshotLog = false, throws = false, signal = false, args = [] }) => {
+  ({snapshotLog = false, throws = false, signal = false, args = []}) => {
     // beforeEach
-    const { sync: crossSpawnSyncMock } = require('cross-spawn');
-    const originalExit = process.exit;
-    const originalArgv = process.argv;
-    const originalLog = console.log;
-    process.exit = jest.fn();
-    console.log = jest.fn();
+    const {sync: crossSpawnSyncMock} = require('cross-spawn')
+    const originalExit = process.exit
+    const originalArgv = process.argv
+    const originalLog = console.log
+    process.exit = jest.fn()
+    console.log = jest.fn()
     try {
       // tests
-      process.argv = ['node', '../', ...args];
-      crossSpawnSyncMock.mockClear();
+      process.argv = ['node', '../', ...args]
+      crossSpawnSyncMock.mockClear()
       if (signal) {
-        crossSpawnSyncMock.mockReturnValueOnce({ result: 1, signal });
+        crossSpawnSyncMock.mockReturnValueOnce({result: 1, signal})
       }
-      require('../');
+      require('../')
       if (snapshotLog) {
-        expect(console.log.mock.calls).toMatchSnapshot();
+        expect(console.log.mock.calls).toMatchSnapshot()
       } else if (signal) {
-        expect(process.exit).toHaveBeenCalledTimes(1);
-        expect(process.exit).toHaveBeenCalledWith(1);
-        expect(console.log.mock.calls).toMatchSnapshot();
+        expect(process.exit).toHaveBeenCalledTimes(1)
+        expect(process.exit).toHaveBeenCalledWith(1)
+        expect(console.log.mock.calls).toMatchSnapshot()
       } else {
-        expect(crossSpawnSyncMock).toHaveBeenCalledTimes(1);
-        const [firstCall] = crossSpawnSyncMock.mock.calls;
-        const [script, calledArgs] = firstCall;
-        expect([script, ...calledArgs].join(' ')).toMatchSnapshot();
+        expect(crossSpawnSyncMock).toHaveBeenCalledTimes(1)
+        const [firstCall] = crossSpawnSyncMock.mock.calls
+        const [script, calledArgs] = firstCall
+        expect([script, ...calledArgs].join(' ')).toMatchSnapshot()
       }
     } catch (error) {
       if (throws) {
-        expect(error.message).toMatchSnapshot();
+        expect(error.message).toMatchSnapshot()
       } else {
-        throw error;
+        throw error
       }
     } finally {
       // afterEach
-      process.exit = originalExit;
-      process.argv = originalArgv;
-      console.log = originalLog;
-      jest.resetModules();
+      process.exit = originalExit
+      process.argv = originalArgv
+      console.log = originalLog
+      jest.resetModules()
     }
   },
   {
@@ -82,6 +82,6 @@ cases(
       signal: 'SIGBREAK',
     },
   },
-);
+)
 
 /* eslint complexity:0 */