v4

.eslintignore

@@ -1 +1,2 @@
 coverage/
+dist/

.eslintrc.json

@@ -8,7 +8,7 @@
   "extends": [
     "plugin:@typescript-eslint/eslint-recommended",
     "plugin:@typescript-eslint/recommended",
-    "prettier/@typescript-eslint",
+    "prettier",
     "plugin:jest/recommended",
     "plugin:jest-formatting/recommended"
   ],

.github/dependabot.yml

@@ -1,7 +1,11 @@
 version: 2
 updates:
-  # Set update schedule for GitHub Actions
-  - package-ecosystem: 'github-actions'
-    directory: '/'
+  - package-ecosystem: github-actions
+    directory: /
     schedule:
-      interval: 'daily'
+      interval: daily
+
+  - package-ecosystem: npm
+    directory: /
+    schedule:
+      interval: daily

.github/workflows/pipeline.yml

@@ -24,6 +24,7 @@ jobs:
         uses: styfle/cancel-workflow-action@0.8.0
         with:
           access_token: ${{ secrets.GITHUB_TOKEN }}
+
       - name: Checkout
         uses: actions/checkout@v2
 
@@ -37,12 +38,14 @@ jobs:
         with:
           useLockFile: false
 
+      - name: Check Types
+        run: npm run type-check
+
       - name: Lint code
         run: npm run lint
 
-      # TODO: reenable on v4 + run tsc
-    #      - name: Check format
-    #        run: npm run format:check
+      - name: Check format
+        run: npm run format:check
 
   tests:
     name: Tests (Node v${{ matrix.node }} - ESLint v${{ matrix.eslint }})
@@ -51,7 +54,7 @@ jobs:
     strategy:
       matrix:
         node: [ '10.12', '10', '12.0', '12', '14' ]
-        eslint: [ '5', '6', '7' ]
+        eslint: [ '7.5', '7' ]
 
     steps:
       - name: Cancel Previous Runs

.huskyrc

@@ -1,6 +1,6 @@
 {
   "hooks": {
-    "pre-commit": "npm run test && lint-staged",
+    "pre-commit": "lint-staged",
     "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
   }
 }

.lintstagedrc

@@ -1,4 +1,8 @@
 {
-  "*.js": ["eslint --fix", "git add"],
-  "*.md": ["prettier --write", "git add"]
+  "*.{js,ts}": [
+    "eslint --max-warnings 0 --fix",
+    "prettier --write",
+    "jest --findRelatedTests"
+  ],
+  "*.md": ["prettier --write"]
 }

.npmrc

@@ -0,0 +1 @@
+package-lock=false

.prettierrc.js

@@ -0,0 +1,3 @@
+module.exports = {
+  singleQuote: true,
+};

.releaserc.json

@@ -0,0 +1,17 @@
+{
+  "pkgRoot": "dist",
+  "branches": [
+    "+([0-9])?(.{+([0-9]),x}).x",
+    "main",
+    "next",
+    "next-major",
+    {
+      "name": "beta",
+      "prerelease": true
+    },
+    {
+      "name": "alpha",
+      "prerelease": true
+    }
+  ]
+}

CODE_OF_CONDUCT.md

@@ -14,22 +14,22 @@ appearance, race, religion, or sexual identity and orientation.
 Examples of behavior that contributes to creating a positive environment
 include:
 
-* Using welcoming and inclusive language
-* Being respectful of differing viewpoints and experiences
-* Gracefully accepting constructive criticism
-* Focusing on what is best for the community
-* Showing empathy towards other community members
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
 
 Examples of unacceptable behavior by participants include:
 
-* The use of sexualized language or imagery and unwelcome sexual attention or
- advances
-* Trolling, insulting/derogatory comments, and personal or political attacks
-* Public or private harassment
-* Publishing others' private information, such as a physical or electronic
- address, without explicit permission
-* Other conduct which could reasonably be considered inappropriate in a
- professional setting
+- The use of sexualized language or imagery and unwelcome sexual attention or
+  advances
+- Trolling, insulting/derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+- Other conduct which could reasonably be considered inappropriate in a
+  professional setting
 
 ## Our Responsibilities
 

CONTRIBUTING.md

@@ -71,7 +71,41 @@ Additionally, you need to do a couple of extra things:
 - 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
+### Custom rule creator
+
+In v4 we introduced several improvements for both the final users as for contributors. Now there is a custom Rule Creator available called `createTestingLibraryRule` which should be the default Rule Creator used in this plugin. This Testing Library Rule Creator extends TSESLint Rule Creator to enhance rules automatically, so it prevents rules to be reported if nothing related to Testing Library found, and injects a 3rd parameter within `create` function: `helpers`.
+
+This new `helpers` available in the `create` of the rule gives you access to a bunch of utils to detect things related to Testing Library. You can find all of them in `detect-testing-library-utils.ts` file, but these are some helpers available:
+
+- `isTestingLibraryImported`
+- `isGetQueryVariant`
+- `isQueryQueryVariant`
+- `isFindQueryVariant`
+- `isSyncQuery`
+- `isAsyncQuery`
+- `isQuery`
+- `isCustomQuery`
+- `isAsyncUtil`
+- `isFireEventUtil`
+- `isUserEventUtil`
+- `isFireEventMethod`
+- `isUserEventMethod`
+- `isRenderUtil`
+- `isRenderVariableDeclarator`
+- `isDebugUtil`
+- `isPresenceAssert`
+- `isAbsenceAssert`
+- `isNodeComingFromTestingLibrary`
+
+Our custom Rule Creator will also take care of common checks like making sure Testing Library is imported, or verify Shared Settings. You don't need to implement anything to check if there is some import related to Testing Library or anything similar in your rule anymore, just stick to the `helpers` received as a 3rd parameter in your `create` function.
+
+If you need some check related to Testing Library which is not available in any existing helper, feel free to implement a new one. You need to make sure to:
+
+- add corresponding type
+- pass it through `helpers`
+- write some generic test within `fake-rule.ts`, which is a dumb rule to be able to test all enhanced behavior from our custom Rule Creator.
+
+## Updating existing rules
 
 A couple of things you need to remember when editing already existing rules:
 
@@ -80,6 +114,32 @@ A couple of things you need to remember when editing already existing rules:
 - Try to add tests to cover the changes introduced, no matter if that's
   a bug fix or a new feature.
 
+## Writing Tests
+
+When writing tests for a new or existing rule, please make sure to follow these guidelines:
+
+### Write real-ish scenarios
+
+Since the plugin will report differently depending on which Testing Library package is imported and what Shared Settings are enabled, writing more realistic scenarios is pretty important. Ideally, you should:
+
+- wrap the code for your rule with a real test file structure, something like
+
+  ```javascript
+  import { render } from '@testing-library/react';
+
+  test('should report invalid render usage', () => {
+    // the following line is the actual code you needed to test your rule,
+    // but everything else helps finding edge cases and makes it more robust.
+    const wrapper = render(<Component />);
+  });
+  ```
+
+- add some extra valid and invalid cases for checking what's the result when some Shared Settings are enabled (so things may or may not be reported depending on the settings), or something named in the same way as a Testing Library util is found, but it's not coming from any Testing Library package (so it shouldn't be reported).
+
+### Check as much as you can from error reported on invalid test cases
+
+Please make sure you check `line`, `column`, `messageId` and `data` (if some) in your invalid test cases to check errors are reported as expected.
+
 ## Help needed
 
 Please check the [the open issues](https://github.com/testing-library/eslint-plugin-testing-library/issues)