jest.mock import rule?

[leeferfeefer]

Does this package have the ability to check that the import string within jest.mock is an absolute import vs relative?

[G-Rath]

No we do not - if you'd like such a rule, could you give some more details on your use case(s) and some examples? (I know it sounds obvious, but sometimes there are hidden behaviours that are easy to miss until you dig a bit deeper)

[leeferfeefer]

I realized I don't need such a thing any more, but I was wanting something that would check that the module path for a relative module within the jest.mock function was an absolute path.

Given a project (lets call it SuperFunProject) that makes use of typescript aliasing and absolute imports that contains a react component and service API:

// ServiceA.ts
export const getData = () => {};



// ReactComponentB.ts
import { getData } from "SuperFunProject/services/ServiceA";




// ReactComponentB.test.ts

jest.mock("");   **<---------** 

it("should test stuff", () => {});

The absolute path here in jest.mock would be "SuperFunProject/services/ServiceA" instead of a relative one which could be "../services/ServiceA". A eslint rule to check this is what I am looking for.

Thank you for your quick response and curiosity!

[richardaum]

I think it it still necessary:

Feature Proposal

I propose an enhancement to the jest.mock function in Jest by implementing a mechanism that allows validation of the string provided to jest.mock. The primary aim of this feature is to improve reliability when mocking dependencies by ensuring the references used in mocks remain accurate, even if the referenced modules or dependencies are moved or removed. Unlike the automatic reference updates in import('module'), this feature would not auto-update the string, but it would facilitate tools such as ESLint to identify when a module reference is invalid and allow them to perform such updates.

Motivation

Currently, the jest.mock function allows us to mock both external dependencies (libraries) and internal modules (JS/TS files). When leveraging tools like VSCode, ESLint, and TypeScript, changes in internal modules and the removal of dependencies are detected before they can cause runtime issues. However, changing the reference of what's being mocked doesn't update the string provided to jest.mock, which can introduce undetected problems during the development cycle. By enabling reference validation, we could circumvent these issues, thereby enhancing Jest's reliability.

Example

If a mock is created for a module called './module', and this module is later moved to a different location, say './new-module', the string provided to jest.mock would still refer to './module'. With the proposed feature, Jest wouldn't automatically update the reference, but it would enable tools like ESLint to identify the invalid reference, and facilitate their mechanisms for updates:

jest.mock('./module', ...);
...
// The module is moved to a new location
import NewModule from './new-module';

// ESLint, or a similar tool, identifies the outdated reference
jest.mock('./new-module', ...);

Pitch

The proposed feature would significantly enhance the Jest testing library, making it more resilient to changes in the code base and the testing environment. It facilitates the use of mocks by ensuring their accuracy and relevance, thus increasing test reliability. Given the crucial role that jest.mock plays in many testing scenarios, it's evident that enhancing its functionality in this manner is a valuable addition to the Jest core platform.

[G-Rath]

@richardaum what you've put is a propose for Jest - could you reframe to focus on eslint-plugin-jest?

Overall I think we should look into having a rule for jest.mock which tries to ensure what's being mocked exists, and should be able to leverage what's been done over in eslint-plugin-import (especially their resolvers which would give us alias support)