From 535992cc265580e85fa3481ea64d92cf6195837b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mario=20Beltra=CC=81n=20Alarco=CC=81n?= Date: Sat, 4 Apr 2020 22:01:20 +0200 Subject: [PATCH 1/6] docs: adding contributing guidelines --- CONTRIBUTING.md | 86 +++++++++++++++++++++++++++++++++++++++++++++++++ package.json | 1 + 2 files changed, 87 insertions(+) create mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 00000000..850e5f9e --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,86 @@ +# Contributing + +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](https://egghead.io/series/how-to-contribute-to-an-open-source-project-on-github). + +## Project setup + +1. Fork this repository +2. Clone your forked repository +3. Run `npm install` to install corresponding dependencies +4. Create a branch for your PR named like `pr/your-branch-name` (you can do this through git CLI with `git checkout -b pr/your-branch-name`) + +> Tip: Keep your `master` branch pointing at the original repository and make +> pull requests from branches on your fork. To do this, run: +> +> ``` +> git remote add upstream https://github.com/testing-library/eslint-plugin-testing-library.git +> git fetch upstream +> 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`. + +## Committing and Pushing changes + +There are git hooks config with this project that are automatically installed +and set up when you install dependencies. This will be run on every commit: + +- check all tests are passing, code validation is fine and format files automatically +- check commit message is following [Conventional Commit specification](https://www.conventionalcommits.org/en/v1.0.0/) + +You can run `npm run test:update` which will update any snapshots that need updating. + +## Rule naming conventions + +Based on [ESLint's Rule Naming Conventions](https://eslint.org/docs/developer-guide/working-with-rules#rule-naming-conventions), this is the simple convention you must follow: + +- If your rule is disallowing something, prefix it with `no-` such as `no-debug` + for disallowing `debug()`. +- If your rule is suggesting to use a specific way for something that can be + done in several ways, you could **optionally** prefix it with `prefer-` such as + `prefer-screen-queries` for suggesting to use `screen.getByText()` from + imported `screen` rather than`getByText()` from `render`'s result, + even though both are technically fine. +- If your rule is enforcing the inclusion of something, use a short name without a special prefix such as `await-async-utils` for enforcing to await proper async utils. +- Use dashes between words. +- Try to keep the name simple. + +## Adding new rules + +In the [same way as ESLint](https://eslint.org/docs/developer-guide/working-with-rules), +each rule has three files named with its identifier (e.g. `no-debug`): + +- in the `lib/rules` directory: a source file (e.g. `no-debug.js`) +- in the `tests/lib/rules` directory: a test file (e.g. `no-debug.js`) +- in the `docs/rules` directory: a Markdown documentation file (e.g. `no-debug.md`) + +Additionally, you need to do couple of extra things: + +- Import the new rule in `lib/index.js` and include it + in `rules` constant. There is a snapshot test which will make sure you did + this, and you can update it just running `npm run test:update`. + Remember to include your rule under corresponding `config` if necessary. +- Include your rule in "Supported Rules" table within `README.md`. + Don't forget to include proper badges if needed. + +## Modifying rules + +Just couple of things you need to remember when editing already existing rules: + +- If renaming a rule, make sure to update all points mentioned in + [Adding new rules](#Adding new rules) section. +- Try to add tests to cover the changes introduced, no matter if that's + a bug fix or a new feature. + +## Help needed + +Please checkout the [the open issues][https://github.com/testing-library/eslint-plugin-testing-library/issues] + +Also, please watch the repo and respond to questions/bug reports/feature requests! Thanks! diff --git a/package.json b/package.json index 359d8cab..f814a770 100644 --- a/package.json +++ b/package.json @@ -30,6 +30,7 @@ "format": "prettier --write README.md {lib,docs,tests}/**/*.{js,md}", "test:local": "jest", "test:ci": "jest --coverage", + "test:update": "npm run test:local -- --u", "test:watch": "npm run test:local -- --watch", "test": "is-ci test:ci test:local", "semantic-release": "semantic-release" From 61bf75e2dab1537a9f18a608eca131547b20b3b5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mario=20Beltra=CC=81n=20Alarco=CC=81n?= Date: Sat, 4 Apr 2020 22:05:51 +0200 Subject: [PATCH 2/6] docs: fix contributing file links --- CONTRIBUTING.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 850e5f9e..11d3e5bb 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -75,12 +75,12 @@ Additionally, you need to do couple of extra things: Just couple of things you need to remember when editing already existing rules: - If renaming a rule, make sure to update all points mentioned in - [Adding new rules](#Adding new rules) section. + "Adding new rules" section. - Try to add tests to cover the changes introduced, no matter if that's a bug fix or a new feature. ## Help needed -Please checkout the [the open issues][https://github.com/testing-library/eslint-plugin-testing-library/issues] +Please checkout the [the open issues](https://github.com/testing-library/eslint-plugin-testing-library/issues) Also, please watch the repo and respond to questions/bug reports/feature requests! Thanks! From 51a5feda232a0a7387a1bc37da6b0786e6300018 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mario=20Beltra=CC=81n=20Alarco=CC=81n?= Date: Mon, 6 Apr 2020 20:58:19 +0200 Subject: [PATCH 3/6] docs: update adding new rules section in contributing --- CONTRIBUTING.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 11d3e5bb..1d5e3dd1 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -64,9 +64,10 @@ each rule has three files named with its identifier (e.g. `no-debug`): Additionally, you need to do couple of extra things: - Import the new rule in `lib/index.js` and include it - in `rules` constant. There is a snapshot test which will make sure you did - this, and you can update it just running `npm run test:update`. - Remember to include your rule under corresponding `config` if necessary. + in `rules` constant (there is a test which will make sure you did + this). Remember to include your rule under corresponding `config` if necessary + (a snapshot test will check this too, but you can update it just running + `npm run test:update`). - Include your rule in "Supported Rules" table within `README.md`. Don't forget to include proper badges if needed. From ca5e846d6c13e5693067013c7245c7f705af0c88 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mario=20Beltr=C3=A1n=20Alarc=C3=B3n?= Date: Tue, 7 Apr 2020 13:32:16 +0200 Subject: [PATCH 4/6] docs: PR feedback Co-Authored-By: Thomas Lombart --- CONTRIBUTING.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 1d5e3dd1..8132ac26 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -30,16 +30,17 @@ Working on your first Pull Request? You can learn how from this free series ## Committing and Pushing changes There are git hooks config with this project that are automatically installed -and set up when you install dependencies. This will be run on every commit: +Git hooks are configured on this project when you install dependencies. The following will be run on every commit: -- check all tests are passing, code validation is fine and format files automatically -- check commit message is following [Conventional Commit specification](https://www.conventionalcommits.org/en/v1.0.0/) +- Lint and format files automatically +- Check all tests are passing +- Check commit message is following [Conventional Commit specification](https://www.conventionalcommits.org/en/v1.0.0/) -You can run `npm run test:update` which will update any snapshots that need updating. +If you ever need to update a snapshot, you can run `npm run test:update` ## Rule naming conventions -Based on [ESLint's Rule Naming Conventions](https://eslint.org/docs/developer-guide/working-with-rules#rule-naming-conventions), this is the simple convention you must follow: +Based on [ESLint's Rule Naming Conventions](https://eslint.org/docs/developer-guide/working-with-rules#rule-naming-conventions), you must follow these rules: - If your rule is disallowing something, prefix it with `no-` such as `no-debug` for disallowing `debug()`. @@ -47,10 +48,10 @@ Based on [ESLint's Rule Naming Conventions](https://eslint.org/docs/developer-gu done in several ways, you could **optionally** prefix it with `prefer-` such as `prefer-screen-queries` for suggesting to use `screen.getByText()` from imported `screen` rather than`getByText()` from `render`'s result, - even though both are technically fine. +- If your rule is suggesting to prefer a way of doing something, among other ways, you can **optionally** prefix it with `prefer-`. For example, `prefer-screen-queries` suggests to use `screen.getByText()` from imported `screen` rather than`getByText()` from `render`'s result though both are technically fine. - If your rule is enforcing the inclusion of something, use a short name without a special prefix such as `await-async-utils` for enforcing to await proper async utils. - Use dashes between words. -- Try to keep the name simple. +- Try to keep the name simple and clear. ## Adding new rules @@ -69,7 +70,7 @@ Additionally, you need to do couple of extra things: (a snapshot test will check this too, but you can update it just running `npm run test:update`). - Include your rule in "Supported Rules" table within `README.md`. - Don't forget to include proper badges if needed. +Don't forget to include the proper badges if needed and to sort alphabetically the rules for readability. ## Modifying rules From 18e17e4d9417798afd2df5aabb8666f3dceebb27 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mario=20Beltra=CC=81n=20Alarco=CC=81n?= Date: Tue, 7 Apr 2020 13:38:29 +0200 Subject: [PATCH 5/6] docs: fix wrong PR suggestions --- CONTRIBUTING.md | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 8132ac26..46ca5b60 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -29,8 +29,8 @@ Working on your first Pull Request? You can learn how from this free series ## Committing and Pushing changes -There are git hooks config with this project that are automatically installed -Git hooks are configured on this project when you install dependencies. The following will be run on every commit: +Git hooks are configured on this project when you install dependencies. +The following will be run on every commit: - Lint and format files automatically - Check all tests are passing @@ -44,12 +44,11 @@ Based on [ESLint's Rule Naming Conventions](https://eslint.org/docs/developer-gu - If your rule is disallowing something, prefix it with `no-` such as `no-debug` for disallowing `debug()`. -- If your rule is suggesting to use a specific way for something that can be - done in several ways, you could **optionally** prefix it with `prefer-` such as - `prefer-screen-queries` for suggesting to use `screen.getByText()` from - imported `screen` rather than`getByText()` from `render`'s result, -- If your rule is suggesting to prefer a way of doing something, among other ways, you can **optionally** prefix it with `prefer-`. For example, `prefer-screen-queries` suggests to use `screen.getByText()` from imported `screen` rather than`getByText()` from `render`'s result though both are technically fine. -- If your rule is enforcing the inclusion of something, use a short name without a special prefix such as `await-async-utils` for enforcing to await proper async utils. +- If your rule is suggesting to prefer a way of doing something, among other ways, you can **optionally** prefix it with + `prefer-`. For example, `prefer-screen-queries` suggests to use `screen.getByText()` from imported `screen` rather + than `getByText()` from `render`'s result though both are technically fine. +- If your rule is enforcing the inclusion of something, use a short name without a special prefix. As an example, + `await-async-utils` enforce to wait for proper async utils. - Use dashes between words. - Try to keep the name simple and clear. @@ -70,7 +69,7 @@ Additionally, you need to do couple of extra things: (a snapshot test will check this too, but you can update it just running `npm run test:update`). - Include your rule in "Supported Rules" table within `README.md`. -Don't forget to include the proper badges if needed and to sort alphabetically the rules for readability. + Don't forget to include the proper badges if needed and to sort alphabetically the rules for readability. ## Modifying rules From b7807c1fc77b50e980d401ae96125c401521afb9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mario=20Beltr=C3=A1n=20Alarc=C3=B3n?= Date: Wed, 8 Apr 2020 11:41:19 +0200 Subject: [PATCH 6/6] docs: More PR feedback Co-Authored-By: Tim Deschryver <28659384+timdeschryver@users.noreply.github.com> --- CONTRIBUTING.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 46ca5b60..c05d4baf 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -61,19 +61,19 @@ each rule has three files named with its identifier (e.g. `no-debug`): - in the `tests/lib/rules` directory: a test file (e.g. `no-debug.js`) - in the `docs/rules` directory: a Markdown documentation file (e.g. `no-debug.md`) -Additionally, you need to do couple of extra things: +Additionally, you need to do a couple of extra things: - Import the new rule in `lib/index.js` and include it in `rules` constant (there is a test which will make sure you did - this). Remember to include your rule under corresponding `config` if necessary + this). Remember to include your rule under corresponding `config` if necessary (a snapshot test will check this too, but you can update it just running `npm run test:update`). -- Include your rule in "Supported Rules" table within `README.md`. +- Include your rule in the "Supported Rules" table within the [README.md](./README.md). Don't forget to include the proper badges if needed and to sort alphabetically the rules for readability. ## Modifying rules -Just couple of things you need to remember when editing already existing rules: +A couple of things you need to remember when editing already existing rules: - If renaming a rule, make sure to update all points mentioned in "Adding new rules" section. @@ -82,6 +82,6 @@ Just couple of things you need to remember when editing already existing rules: ## Help needed -Please checkout the [the open issues](https://github.com/testing-library/eslint-plugin-testing-library/issues) +Please check the [the open issues](https://github.com/testing-library/eslint-plugin-testing-library/issues) Also, please watch the repo and respond to questions/bug reports/feature requests! Thanks!