From 0e88ff9c6de260462738caf816ea3bccef4b9cb3 Mon Sep 17 00:00:00 2001 From: Josh Goldberg Date: Tue, 4 Jun 2024 07:57:33 -0400 Subject: [PATCH 1/3] docs: mention testing changes and keeping PRs up-to-date in PR docs --- docs/contributing/Local_Development.mdx | 17 -------------- docs/contributing/Pull_Requests.mdx | 30 ++++++++++++++++++++++++- 2 files changed, 29 insertions(+), 18 deletions(-) diff --git a/docs/contributing/Local_Development.mdx b/docs/contributing/Local_Development.mdx index 725e9354b32e..ad9e201d22b6 100644 --- a/docs/contributing/Local_Development.mdx +++ b/docs/contributing/Local_Development.mdx @@ -61,23 +61,6 @@ You can run `yarn test` in any package to run its tests. > [VS Code launch tasks](https://code.visualstudio.com/docs/editor/tasks) tasks are provided that allow [visual debugging](https://code.visualstudio.com/docs/editor/debugging) tests. -#### Code Coverage - -We aim for 100% code coverage in all PRs when possible, except in the `website/` package. -Coverage reports are generated locally whenever `yarn test` is run. - -The `codecov` bot should also comment on your PR with the percentage, as well as links to the line-by-line coverage of each file touched by your PR. - -#### Granular Unit Tests - -Most tests in most packages are set up as small, self-contained unit tests. -We generally prefer that to keep tests and their failure reports granular. - -For rule tests we recommend, when reasonable: - -- Including both `valid` and `invalid` code changes in most PRs that affect rule behavior -- Limiting to one error per `invalid` case - ### Type Checking All code should pass TypeScript type checking. diff --git a/docs/contributing/Pull_Requests.mdx b/docs/contributing/Pull_Requests.mdx index dd3a0e4f2d69..0ad53b889d6e 100644 --- a/docs/contributing/Pull_Requests.mdx +++ b/docs/contributing/Pull_Requests.mdx @@ -25,7 +25,26 @@ Please don't: - Comment on a closed PR - Reasoning: It is much easier for maintainers to not lose track of things if they are posted as issues. If you think there's a bug in typescript-eslint, the right way to ask is to [file a new issue](https://github.com/typescript-eslint/typescript-eslint/issues/new/choose). The issue templates include helpful & necessary practices such as making sure you're on the latest version of all our packages. You can provide the link to the relevant PR to add more context. -### Raising a PR +### Testing Changes + +#### Code Coverage + +We aim for 100% code coverage in all PRs when possible, except in the `website/` package. +Coverage reports are generated locally whenever `yarn test` is run. + +The `codecov` bot also comments on each PR with its percentage, as well as links to the line-by-line coverage of each file touched by the PR. + +#### Granular Unit Tests + +Most tests in most packages are set up as small, self-contained unit tests. +We generally prefer that to keep tests and their failure reports granular. + +For rule tests we recommend, when reasonable: + +- Including both `valid` and `invalid` code changes in most PRs that affect rule behavior +- Limiting to one error per `invalid` case + +### Raising the PR Once your changes are ready, you can raise a PR! 🙌 The title of your PR should match the following format: @@ -84,6 +103,15 @@ Once you've addressed all our feedback by making code changes and/or started a f Once the feedback is addressed, and the PR is approved, we'll ensure the branch is up to date with `main`, and merge it for you. +#### Updating Over Time + +You generally don't need to keep merging commits from `main` into your PR branch. +If you see merge conflicts or other intersections that worry you, then you can preemptively - but that's optional. + +If we think merge conflicts need to be resolved in order to merge and/or review a PR, we might do that for you as a courtesy _if_ we have time. +If not, we may ask you to. +If a PR spent an unusually long time to get a review, we'll try our best to find the time to find the time. + ### Asking Questions If you need help and/or have a question, posting a comment in the PR is a great way to do so. From a1b78b4141ac2413bece6215af6ce25406db9531 Mon Sep 17 00:00:00 2001 From: Josh Goldberg Date: Tue, 4 Jun 2024 12:00:08 -0400 Subject: [PATCH 2/3] correct phrasing with finding the time --- docs/contributing/Pull_Requests.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/contributing/Pull_Requests.mdx b/docs/contributing/Pull_Requests.mdx index 0ad53b889d6e..2c6fffb9d9ee 100644 --- a/docs/contributing/Pull_Requests.mdx +++ b/docs/contributing/Pull_Requests.mdx @@ -110,7 +110,7 @@ If you see merge conflicts or other intersections that worry you, then you can p If we think merge conflicts need to be resolved in order to merge and/or review a PR, we might do that for you as a courtesy _if_ we have time. If not, we may ask you to. -If a PR spent an unusually long time to get a review, we'll try our best to find the time to find the time. +If a PR spent an unusually long time to get a review, we'll try our best to find the time to help with merging. ### Asking Questions From 805db5feaa17ea38d78955e4a4153a50875da0c1 Mon Sep 17 00:00:00 2001 From: Josh Goldberg Date: Tue, 4 Jun 2024 14:16:58 -0400 Subject: [PATCH 3/3] remove sentence --- docs/contributing/Pull_Requests.mdx | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/contributing/Pull_Requests.mdx b/docs/contributing/Pull_Requests.mdx index 2c6fffb9d9ee..a0b9ad083b06 100644 --- a/docs/contributing/Pull_Requests.mdx +++ b/docs/contributing/Pull_Requests.mdx @@ -110,7 +110,6 @@ If you see merge conflicts or other intersections that worry you, then you can p If we think merge conflicts need to be resolved in order to merge and/or review a PR, we might do that for you as a courtesy _if_ we have time. If not, we may ask you to. -If a PR spent an unusually long time to get a review, we'll try our best to find the time to help with merging. ### Asking Questions