[new-rule] prefer importing from @jest/globals

It would be nice to have a rule (with fixer) enforcing that APIs such as expect, describe, it, jest, etc should be imported from @jest/globals. If there’s interest in this rule, I’d probably be willing to implement it.

Motivation:

• Reduce global type pollution by not needing to put "types": ["jest"] in a tsconfig
• Allow removing dependency on @types/jest which can be outdated, mismatched, and/or pull in extra versions of packages (this is an issue as of writing–jest 28 has released but the types are still on 27 and pull in some outdated deps from 27)
• Unblock adoption of future mode with globals unavailable once that’s implemented (I’m not sure where that is on their roadmap)

Here’s an example of code with the rule enabled, and an error it might catch:

import { describe, it, expect, jest } from '@jest/globals';
import { foo } from './foo';

describe('foo', () => {
  // ERROR - you forgot to import beforeAll
  beforeAll(() => {
    jest.useFakeTimers();
  });

  it('does stuff', () => {
    expect(foo()).toBe(0);
  });
});

(I assume this would be blocked by #556, but looks like there’s an approved PR #1094 addressing that.)

[ecraig12345]

I’m fine with waiting on the work you have in progress.

I had noticed the no-jest-import rule as well. Expanding it to cover @jest/globals seems like a breaking change, especially with that rule being part of the recommended config. The intent is also different: importing from jest does literally nothing and is never desirable that I’m aware of, whereas whether to import from @jest/globals vs. using ambient globals (and referencing @types/jest for typescript) is a style preference.

[SimenB]

Note that you can run jest with injectGlobals: false and at least get runtime errors today. I doubt we’ll ever change the default, but who knows 🙂 It’s at least only a config option away