@depup/eslint-plugin-jest 29.15.1-depup.0

package/docs/rules/no-export.md

@@ -0,0 +1,52 @@
+# jest/no-export
+
+📝 Disallow using `exports` in files containing tests.
+
+💼 This rule is enabled in the ✅ `recommended`
+[config](https://github.com/jest-community/eslint-plugin-jest/blob/main/README.md#shareable-configurations).
+
+<!-- end auto-generated rule header -->
+
+Prevents using `exports` if a file has one or more tests in it.
+
+## Rule details
+
+This rule aims to eliminate duplicate runs of tests by exporting things from
+test files. If you import from a test file, then all the tests in that file will
+be run in each imported instance, so bottom line, don't export from a test, but
+instead move helper functions into a separate file when they need to be shared
+across tests.
+
+Examples of **incorrect** code for this rule:
+
+```js
+export function myHelper() {}
+
+module.exports = function () {};
+
+module.exports = {
+  something: 'that should be moved to a non-test file',
+};
+
+describe('a test', () => {
+  expect(1).toBe(1);
+});
+```
+
+Examples of **correct** code for this rule:
+
+```js
+function myHelper() {}
+
+const myThing = {
+  something: 'that can live here',
+};
+
+describe('a test', () => {
+  expect(1).toBe(1);
+});
+```
+
+## When Not To Use It
+
+Don't use this rule on non-jest test files.

package/docs/rules/no-focused-tests.md

@@ -0,0 +1,67 @@
+# jest/no-focused-tests
+
+📝 Disallow focused tests.
+
+💼 This rule is enabled in the ✅ `recommended`
+[config](https://github.com/jest-community/eslint-plugin-jest/blob/main/README.md#shareable-configurations).
+
+💡 This rule is manually fixable by
+[editor suggestions](https://eslint.org/docs/latest/use/core-concepts#rule-suggestions).
+
+<!-- end auto-generated rule header -->
+
+<!-- prettier-ignore -->
+Jest has a feature that allows you to focus tests by appending `.only` or
+prepending `f` to a test-suite or a test-case. This feature is really helpful to
+debug a failing test, so you don’t have to execute all of your tests. After you
+have fixed your test and before committing the changes you have to remove
+`.only` to ensure all tests are executed on your build system.
+
+This rule reminds you to remove `.only` from your tests by raising a warning
+whenever you are using the exclusivity feature.
+
+## Rule details
+
+This rule looks for every `describe.only`, `it.only`, `test.only`, `fdescribe`,
+and `fit` occurrences within the source code. Of course there are some
+edge-cases which can’t be detected by this rule e.g.:
+
+```js
+const describeOnly = describe.only;
+describeOnly.apply(describe);
+```
+
+The following patterns are considered warnings:
+
+```js
+describe.only('foo', () => {});
+it.only('foo', () => {});
+describe['only']('bar', () => {});
+it['only']('bar', () => {});
+test.only('foo', () => {});
+test['only']('bar', () => {});
+fdescribe('foo', () => {});
+fit('foo', () => {});
+fit.each`
+  table
+`();
+```
+
+These patterns would not be considered warnings:
+
+```js
+describe('foo', () => {});
+it('foo', () => {});
+describe.skip('bar', () => {});
+it.skip('bar', () => {});
+test('foo', () => {});
+test.skip('bar', () => {});
+it.each()();
+it.each`
+  table
+`();
+test.each()();
+test.each`
+  table
+`();
+```

package/docs/rules/no-hooks.md

@@ -0,0 +1,178 @@
+# jest/no-hooks
+
+📝 Disallow setup and teardown hooks.
+
+<!-- end auto-generated rule header -->
+
+Jest provides global functions for setup and teardown tasks, which are called
+before/after each test case and each test suite. The use of these hooks promotes
+shared state between tests.
+
+## Rule details
+
+This rule reports for the following function calls:
+
+- `beforeAll`
+- `beforeEach`
+- `afterAll`
+- `afterEach`
+
+Examples of **incorrect** code for this rule:
+
+```js
+/* eslint jest/no-hooks: "error" */
+
+function setupFoo(options) {
+  /* ... */
+}
+
+function setupBar(options) {
+  /* ... */
+}
+
+describe('foo', () => {
+  let foo;
+
+  beforeEach(() => {
+    foo = setupFoo();
+  });
+
+  afterEach(() => {
+    foo = null;
+  });
+
+  it('does something', () => {
+    expect(foo.doesSomething()).toBe(true);
+  });
+
+  describe('with bar', () => {
+    let bar;
+
+    beforeEach(() => {
+      bar = setupBar();
+    });
+
+    afterEach(() => {
+      bar = null;
+    });
+
+    it('does something with bar', () => {
+      expect(foo.doesSomething(bar)).toBe(true);
+    });
+  });
+});
+```
+
+Examples of **correct** code for this rule:
+
+```js
+/* eslint jest/no-hooks: "error" */
+
+function setupFoo(options) {
+  /* ... */
+}
+
+function setupBar(options) {
+  /* ... */
+}
+
+describe('foo', () => {
+  it('does something', () => {
+    const foo = setupFoo();
+    expect(foo.doesSomething()).toBe(true);
+  });
+
+  it('does something with bar', () => {
+    const foo = setupFoo();
+    const bar = setupBar();
+    expect(foo.doesSomething(bar)).toBe(true);
+  });
+});
+```
+
+## Options
+
+```json
+{
+  "jest/no-hooks": [
+    "error",
+    {
+      "allow": ["afterEach", "afterAll"]
+    }
+  ]
+}
+```
+
+### `allow`
+
+This array option controls which Jest hooks are checked by this rule. There are
+four possible values:
+
+- `"beforeAll"`
+- `"beforeEach"`
+- `"afterAll"`
+- `"afterEach"`
+
+By default, none of these options are enabled (the equivalent of
+`{ "allow": [] }`).
+
+Examples of **incorrect** code for the `{ "allow": ["afterEach"] }` option:
+
+```js
+/* eslint jest/no-hooks: ["error", { "allow": ["afterEach"] }] */
+
+function setupFoo(options) {
+  /* ... */
+}
+
+let foo;
+
+beforeEach(() => {
+  foo = setupFoo();
+});
+
+afterEach(() => {
+  jest.resetModules();
+});
+
+test('foo does this', () => {
+  // ...
+});
+
+test('foo does that', () => {
+  // ...
+});
+```
+
+Examples of **correct** code for the `{ "allow": ["afterEach"] }` option:
+
+```js
+/* eslint jest/no-hooks: ["error", { "allow": ["afterEach"] }] */
+
+function setupFoo(options) {
+  /* ... */
+}
+
+afterEach(() => {
+  jest.resetModules();
+});
+
+test('foo does this', () => {
+  const foo = setupFoo();
+  // ...
+});
+
+test('foo does that', () => {
+  const foo = setupFoo();
+  // ...
+});
+```
+
+## When Not To Use It
+
+If you prefer using the setup and teardown hooks provided by Jest, you can
+safely disable this rule.
+
+## Further Reading
+
+- [Jest docs - Setup and Teardown](https://jestjs.io/docs/setup-teardown)

package/docs/rules/no-identical-title.md

@@ -0,0 +1,59 @@
+# jest/no-identical-title
+
+📝 Disallow identical titles.
+
+💼 This rule is enabled in the ✅ `recommended`
+[config](https://github.com/jest-community/eslint-plugin-jest/blob/main/README.md#shareable-configurations).
+
+<!-- end auto-generated rule header -->
+
+Having identical titles for two different tests or test suites may create
+confusion. For example, when a test with the same title as another test in the
+same test suite fails, it is harder to know which one failed and thus harder to
+fix.
+
+## Rule details
+
+This rule looks at the title of every test and test suite. It will report when
+two test suites or two test cases at the same level of a test suite have the
+same title.
+
+The following patterns are considered warnings:
+
+```js
+describe('foo', () => {
+  it('should do bar', () => {});
+  it('should do bar', () => {}); // Has the same title as the previous test
+
+  describe('baz', () => {
+    // ...
+  });
+
+  describe('baz', () => {
+    // Has the same title as a previous test suite
+    // ...
+  });
+});
+```
+
+These patterns would not be considered warnings:
+
+```js
+describe('foo', () => {
+  it('should do foo', () => {});
+  it('should do bar', () => {});
+
+  // Has the same name as a parent test suite, which is fine
+  describe('foo', () => {
+    // Has the same name as a test in a parent test suite, which is fine
+    it('should do foo', () => {});
+    it('should work', () => {});
+  });
+
+  describe('baz', () => {
+    // Has the same title as a previous test suite
+    // Has the same name as a test in a sibling test suite, which is fine
+    it('should work', () => {});
+  });
+});
+```

package/docs/rules/no-interpolation-in-snapshots.md

@@ -0,0 +1,67 @@
+# jest/no-interpolation-in-snapshots
+
+📝 Disallow string interpolation inside snapshots.
+
+💼 This rule is enabled in the ✅ `recommended`
+[config](https://github.com/jest-community/eslint-plugin-jest/blob/main/README.md#shareable-configurations).
+
+<!-- end auto-generated rule header -->
+
+Prevents the use of string interpolations in snapshots.
+
+## Rule details
+
+Interpolation prevents snapshots from being updated. Instead, properties should
+be overloaded with a matcher by using
+[property matchers](https://jestjs.io/docs/en/snapshot-testing#property-matchers).
+
+Examples of **incorrect** code for this rule:
+
+```js
+expect(something).toMatchInlineSnapshot(
+  `Object {
+    property: ${interpolated}
+  }`,
+);
+
+expect(something).toMatchInlineSnapshot(
+  { other: expect.any(Number) },
+  `Object {
+    other: Any<Number>,
+    property: ${interpolated}
+  }`,
+);
+
+expect(errorThrowingFunction).toThrowErrorMatchingInlineSnapshot(
+  `${interpolated}`,
+);
+```
+
+Examples of **correct** code for this rule:
+
+```js
+expect(something).toMatchInlineSnapshot();
+
+expect(something).toMatchInlineSnapshot(
+  `Object {
+    property: 1
+  }`,
+);
+
+expect(something).toMatchInlineSnapshot(
+  { property: expect.any(Date) },
+  `Object {
+    property: Any<Date>
+  }`,
+);
+
+expect(errorThrowingFunction).toThrowErrorMatchingInlineSnapshot();
+
+expect(errorThrowingFunction).toThrowErrorMatchingInlineSnapshot(
+  `Error Message`,
+);
+```
+
+## When Not To Use It
+
+Don't use this rule on non-jest test files.

package/docs/rules/no-jasmine-globals.md

@@ -0,0 +1,69 @@
+# jest/no-jasmine-globals
+
+📝 Disallow Jasmine globals.
+
+💼 This rule is enabled in the ✅ `recommended`
+[config](https://github.com/jest-community/eslint-plugin-jest/blob/main/README.md#shareable-configurations).
+
+🔧 This rule is automatically fixable by the
+[`--fix` CLI option](https://eslint.org/docs/latest/user-guide/command-line-interface#--fix).
+
+<!-- end auto-generated rule header -->
+
+`jest` uses `jasmine` as a test runner. A side effect of this is that both a
+`jasmine` object, and some jasmine-specific globals, are exposed to the test
+environment. Most functionality offered by Jasmine has been ported to Jest, and
+the Jasmine globals will stop working in the future. Developers should therefore
+migrate to Jest's documented API instead of relying on the undocumented Jasmine
+API.
+
+## Rule details
+
+This rule reports on any usage of Jasmine globals, which is not ported to Jest,
+and suggests alternatives from Jest's own API.
+
+## Examples
+
+The following patterns are considered warnings:
+
+```js
+jasmine.DEFAULT_TIMEOUT_INTERVAL = 5000;
+
+test('my test', () => {
+  pending();
+});
+
+test('my test', () => {
+  fail();
+});
+
+test('my test', () => {
+  spyOn(some, 'object');
+});
+
+test('my test', () => {
+  jasmine.createSpy();
+});
+
+test('my test', () => {
+  expect('foo').toEqual(jasmine.anything());
+});
+```
+
+The following patterns would not be considered warnings:
+
+```js
+jest.setTimeout(5000);
+
+test('my test', () => {
+  jest.spyOn(some, 'object');
+});
+
+test('my test', () => {
+  jest.fn();
+});
+
+test('my test', () => {
+  expect('foo').toEqual(expect.anything());
+});
+```

package/docs/rules/no-large-snapshots.md

@@ -0,0 +1,180 @@
+# jest/no-large-snapshots
+
+📝 Disallow large snapshots.
+
+<!-- end auto-generated rule header -->
+
+When using Jest's snapshot capability one should be mindful of the size of
+created snapshots. As a general best practice snapshots should be limited in
+size in order to be more manageable and reviewable. A stored snapshot is only as
+good as its review and as such keeping it short, sweet, and readable is
+important to allow for thorough reviews.
+
+## Usage
+
+Because Jest snapshots are written with back-ticks (\` \`) which are only valid
+with
+[ES2015 onwards](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals)
+you should set `parserOptions` in your config to at least allow ES2015 in order
+to use this rule:
+
+```js
+module.exports = {
+  parserOptions: {
+    ecmaVersion: 2015,
+  },
+};
+```
+
+In order to check external snapshots, you must also have `eslint` check files
+with the `.snap` extension by either passing `--ext snap` on the command line or
+by explicitly specifying `.snap` in `overrides`.
+
+## Rule details
+
+This rule looks at all Jest inline and external snapshots (files with `.snap`
+extension) and validates that each stored snapshot within those files does not
+exceed 50 lines (by default, this is configurable as explained in `Options`
+section below).
+
+Example of **incorrect** code for this rule:
+
+```js
+exports[`a large snapshot 1`] = `
+line 1
+line 2
+line 3
+line 4
+line 5
+line 6
+line 7
+line 8
+line 9
+line 10
+line 11
+line 12
+line 13
+line 14
+line 15
+line 16
+line 17
+line 18
+line 19
+line 20
+line 21
+line 22
+line 23
+line 24
+line 25
+line 26
+line 27
+line 28
+line 29
+line 30
+line 31
+line 32
+line 33
+line 34
+line 35
+line 36
+line 37
+line 38
+line 39
+line 40
+line 41
+line 42
+line 43
+line 44
+line 45
+line 46
+line 47
+line 48
+line 49
+line 50
+line 51
+`;
+```
+
+Example of **correct** code for this rule:
+
+```js
+exports[`a more manageable and readable snapshot 1`] = `
+line 1
+line 2
+line 3
+line 4
+`;
+```
+
+## Options
+
+This rule has options for modifying the max number of lines allowed for a
+snapshot:
+
+In an `eslintrc` file:
+
+```json
+{
+  "rules": {
+    "jest/no-large-snapshots": ["warn", { "maxSize": 12, "inlineMaxSize": 6 }]
+  }
+}
+```
+
+Max number of lines allowed could be defined by snapshot type (Inline and
+External). Use `inlineMaxSize` for
+[Inline Snapshots](https://jestjs.io/docs/en/snapshot-testing#inline-snapshots)
+size and `maxSize` for
+[External Snapshots](https://jestjs.io/docs/en/snapshot-testing#snapshot-testing-with-jest).
+If only `maxSize` is provided on options, the value of `maxSize` will be used
+for both snapshot types (Inline and External).
+
+Since `eslint-disable` comments are not preserved by Jest when updating
+snapshots, you can use the `allowedSnapshots` option to have specific snapshots
+allowed regardless of their size.
+
+This option takes a map, with the key being the absolute filepath to a snapshot
+file, and the value an array of values made up of strings and regular
+expressions to compare to the names of the snapshots in the `.snap` file when
+checking if the snapshots size should be allowed.
+
+Note that regular expressions can only be passed in via `.eslintrc.js` as
+instances of `RegExp`.
+
+In an `.eslintrc.js` file:
+
+```javascript
+module.exports = {
+  rules: {
+    'jest/no-large-snapshots': [
+      'error',
+      {
+        allowedSnapshots: {
+          '/path/to/file.js.snap': ['snapshot name 1', /a big snapshot \d+/],
+        },
+      },
+    ],
+  },
+};
+```
+
+Since absolute paths are typically not very portable, you can use the builtin
+`path.resolve` function to expand relative paths into absolutes like so:
+
+```javascript
+const path = require('path');
+
+module.exports = {
+  rules: {
+    'jest/no-large-snapshots': [
+      'error',
+      {
+        allowedSnapshots: {
+          [path.resolve('test/__snapshots__/get.js.snap')]: ['full request'],
+          [path.resolve('test/__snapshots__/put.js.snap')]: ['full request'],
+        },
+      },
+    ],
+  },
+};
+```

package/docs/rules/no-mocks-import.md

@@ -0,0 +1,34 @@
+# jest/no-mocks-import
+
+📝 Disallow manually importing from `__mocks__`.
+
+💼 This rule is enabled in the ✅ `recommended`
+[config](https://github.com/jest-community/eslint-plugin-jest/blob/main/README.md#shareable-configurations).
+
+<!-- end auto-generated rule header -->
+
+When using `jest.mock`, your tests (just like the code being tested) should
+import from `./x`, not `./__mocks__/x`. Not following this rule can lead to
+confusion, because you will have multiple instances of the mocked module:
+
+```js
+jest.mock('./x');
+const x1 = require('./x');
+const x2 = require('./__mocks__/x');
+
+test('x', () => {
+  expect(x1).toBe(x2); // fails! They are both instances of `./__mocks__/x`, but not referentially equal
+});
+```
+
+## Rule details
+
+This rule reports imports from a path containing a `__mocks__` component.
+
+Example violations:
+
+```js
+import thing from './__mocks__/index';
+require('./__mocks__/index');
+require('__mocks__');
+```