chore: format all the things

Author: Kent C. Dodds

.github/PULL_REQUEST_TEMPLATE.md

@@ -36,6 +36,7 @@ merge of your pull request!
 
 - [ ] Documentation
 - [ ] Tests
-- [ ] Ready to be merged <!-- In your opinion, is this ready to be merged as soon as it's reviewed? -->
+- [ ] Ready to be merged
+      <!-- In your opinion, is this ready to be merged as soon as it's reviewed? -->
 
 <!-- feel free to add additional comments -->

.prettierrc

@@ -6,5 +6,6 @@
   "singleQuote": true,
   "trailingComma": "all",
   "bracketSpacing": false,
-  "jsxBracketSameLine": false
+  "jsxBracketSameLine": false,
+  "proseWrap": "always"
 }

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
 
@@ -20,18 +20,17 @@ 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
 
 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 into git hooks
 
@@ -52,5 +51,6 @@ 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
 [issues]: https://github.com/kentcdodds/cypress-testing-library/issues

README.md

@@ -7,21 +7,20 @@
 
 <p>Simple and complete custom Cypress commands and utilities that encourage good testing practices.</p>
 
-[**Read the docs**](https://testing-library.com/cypress) | [Edit the docs](https://github.com/alexkrolick/testing-library-docs)
+[**Read the docs**](https://testing-library.com/cypress) |
+[Edit the docs](https://github.com/alexkrolick/testing-library-docs)
 
 </div>
 
 <hr />
 
 [![Build Status][build-badge]][build]
 [![Code Coverage][coverage-badge]][coverage]
-[![version][version-badge]][package]
-[![downloads][downloads-badge]][npmtrends]
+[![version][version-badge]][package] [![downloads][downloads-badge]][npmtrends]
 [![MIT License][license-badge]][license]
 
 [![All Contributors](https://img.shields.io/badge/all_contributors-10-orange.svg?style=flat-square)](#contributors)
-[![PRs Welcome][prs-badge]][prs]
-[![Code of Conduct][coc-badge]][coc]
+[![PRs Welcome][prs-badge]][prs] [![Code of Conduct][coc-badge]][coc]
 
 [![Watch on GitHub][github-watch-badge]][github-watch]
 [![Star on GitHub][github-star-badge]][github-star]
@@ -35,11 +34,13 @@
 
 ## The problem
 
-You want to use [`dom-testing-library`][dom-testing-library] methods in your [Cypress][cypress] tests.
+You want to use [`dom-testing-library`][dom-testing-library] methods in your
+[Cypress][cypress] tests.
 
 ## This solution
 
-This allows you to use all the useful [`dom-testing-library`][dom-testing-library] methods in your tests.
+This allows you to use all the useful
+[`dom-testing-library`][dom-testing-library] methods in your tests.
 
 ## Table of Contents
 
@@ -66,7 +67,8 @@ npm install --save-dev cypress-testing-library
 
 ### With typescript
 
-Typings are defined under `cypress-testing-library/typings`, and should be added as follows in `tsconfig.json`:
+Typings are defined under `cypress-testing-library/typings`, and should be added
+as follows in `tsconfig.json`:
 
 ```json
 {
@@ -86,9 +88,12 @@ Add this line to your project's `cypress/support/commands.js`:
 import 'cypress-testing-library/add-commands';
 ```
 
-You can now use all of `dom-testing-library`'s `getBy`, `getAllBy`, `queryBy` and `queryAllBy` commands. [See `dom-testing-library` repo for reference](https://github.com/kentcdodds/dom-testing-library#usage)
+You can now use all of `dom-testing-library`'s `getBy`, `getAllBy`, `queryBy`
+and `queryAllBy` commands.
+[See `dom-testing-library` repo for reference](https://github.com/kentcdodds/dom-testing-library#usage)
 
-To show some simple examples (from [cypress/integration/commands.spec.js](cypress/integration/commands.spec.js)):
+To show some simple examples (from
+[cypress/integration/commands.spec.js](cypress/integration/commands.spec.js)):
 
 ```javascript
 cy.getAllByText('Jackie Chan').click()
@@ -103,7 +108,11 @@ cy.get('form').then(subject => {
 })
 ```
 
-`cypress-testing-library` supports both jQuery elements and DOM nodes. This is necessary because Cypress uses jQuery elements, while `dom-testing-library` expects DOM nodes. When you pass a jQuery element as `container`, it will get the first DOM node from the collection and use that as the `container` parameter for the `dom-testing-library` functions.
+`cypress-testing-library` supports both jQuery elements and DOM nodes. This is
+necessary because Cypress uses jQuery elements, while `dom-testing-library`
+expects DOM nodes. When you pass a jQuery element as `container`, it will get
+the first DOM node from the collection and use that as the `container` parameter
+for the `dom-testing-library` functions.
 
 ## Other Solutions
 
@@ -131,27 +140,41 @@ MIT
 
 [npm]: https://www.npmjs.com/
 [node]: https://nodejs.org
-[build-badge]: https://img.shields.io/travis/kentcdodds/cypress-testing-library.svg?style=flat-square
+[build-badge]:
+  https://img.shields.io/travis/kentcdodds/cypress-testing-library.svg?style=flat-square
 [build]: https://travis-ci.org/kentcdodds/cypress-testing-library
-[coverage-badge]: https://img.shields.io/codecov/c/github/kentcdodds/cypress-testing-library.svg?style=flat-square
+[coverage-badge]:
+  https://img.shields.io/codecov/c/github/kentcdodds/cypress-testing-library.svg?style=flat-square
 [coverage]: https://codecov.io/github/kentcdodds/cypress-testing-library
-[version-badge]: https://img.shields.io/npm/v/cypress-testing-library.svg?style=flat-square
+[version-badge]:
+  https://img.shields.io/npm/v/cypress-testing-library.svg?style=flat-square
 [package]: https://www.npmjs.com/package/cypress-testing-library
-[downloads-badge]: https://img.shields.io/npm/dm/cypress-testing-library.svg?style=flat-square
+[downloads-badge]:
+  https://img.shields.io/npm/dm/cypress-testing-library.svg?style=flat-square
 [npmtrends]: http://www.npmtrends.com/cypress-testing-library
-[license-badge]: https://img.shields.io/npm/l/cypress-testing-library.svg?style=flat-square
-[license]: https://github.com/kentcdodds/cypress-testing-library/blob/master/LICENSE
-[prs-badge]: https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square
+[license-badge]:
+  https://img.shields.io/npm/l/cypress-testing-library.svg?style=flat-square
+[license]:
+  https://github.com/kentcdodds/cypress-testing-library/blob/master/LICENSE
+[prs-badge]:
+  https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square
 [prs]: http://makeapullrequest.com
-[donate-badge]: https://img.shields.io/badge/$-support-green.svg?style=flat-square
-[coc-badge]: https://img.shields.io/badge/code%20of-conduct-ff69b4.svg?style=flat-square
-[coc]: https://github.com/kentcdodds/cypress-testing-library/blob/master/other/CODE_OF_CONDUCT.md
-[github-watch-badge]: https://img.shields.io/github/watchers/kentcdodds/cypress-testing-library.svg?style=social
+[donate-badge]:
+  https://img.shields.io/badge/$-support-green.svg?style=flat-square
+[coc-badge]:
+  https://img.shields.io/badge/code%20of-conduct-ff69b4.svg?style=flat-square
+[coc]:
+  https://github.com/kentcdodds/cypress-testing-library/blob/master/other/CODE_OF_CONDUCT.md
+[github-watch-badge]:
+  https://img.shields.io/github/watchers/kentcdodds/cypress-testing-library.svg?style=social
 [github-watch]: https://github.com/kentcdodds/cypress-testing-library/watchers
-[github-star-badge]: https://img.shields.io/github/stars/kentcdodds/cypress-testing-library.svg?style=social
+[github-star-badge]:
+  https://img.shields.io/github/stars/kentcdodds/cypress-testing-library.svg?style=social
 [github-star]: https://github.com/kentcdodds/cypress-testing-library/stargazers
-[twitter]: https://twitter.com/intent/tweet?text=Check%20out%20cypress-testing-library%20by%20%40kentcdodds%20https%3A%2F%2Fgithub.com%2Fkentcdodds%2Fcypress-testing-library%20%F0%9F%91%8D
-[twitter-badge]: https://img.shields.io/twitter/url/https/github.com/kentcdodds/cypress-testing-library.svg?style=social
+[twitter]:
+  https://twitter.com/intent/tweet?text=Check%20out%20cypress-testing-library%20by%20%40kentcdodds%20https%3A%2F%2Fgithub.com%2Fkentcdodds%2Fcypress-testing-library%20%F0%9F%91%8D
+[twitter-badge]:
+  https://img.shields.io/twitter/url/https/github.com/kentcdodds/cypress-testing-library.svg?style=social
 [emojis]: https://github.com/kentcdodds/all-contributors#emoji-key
 [all-contributors]: https://github.com/kentcdodds/all-contributors
 [dom-testing-library]: https://github.com/kentcdodds/dom-testing-library

other/CODE_OF_CONDUCT.md

@@ -5,9 +5,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
 
@@ -37,11 +37,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
 
@@ -58,17 +58,18 @@ Instances of abusive, harassing, or otherwise unacceptable behavior may be
 reported by contacting the project team at [email protected]. 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

@@ -4,60 +4,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

@@ -1,9 +1,10 @@
 # manual-releases
 
-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**