Update test framework mock paths during file rename operations

[hjonasson]

🔍 Search Terms

All searched terms
"jest"
"mock"
"vitest"
"filename"
"rename" (this is NOT a rename default export when file name changes request)

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

When renaming or moving files in TypeScript projects, the language service should automatically update string literal paths in test framework mocking functions (e.g., jest.mock(), vitest.mock()) in addition to standard import statements.

Use Cases

When you rename/move a file, TypeScript updates imports but not mock paths:

// Before renaming helper.ts → utils/helper.ts
import { helper } from "./helper";
jest.mock("./helper");  // ❌ Not updated - breaks tests!

// After rename
import { helper } from "./utils/helper";  // ✅ Updated automatically
jest.mock("./helper");  // ❌ Still points to old location - test fails

This leads to:

• Broken tests after refactoring
• Manual find-and-replace operations
• Time wasted tracking down test failures
• More tedium when reorganizing code structure

Desired Behavior

After renaming/moving a file, both imports and mock paths should update:

// Before renaming helper.ts → utils/helper.ts
import { helper } from "./helper";
jest.mock("./helper");

// After rename
import { helper } from "./utils/helper";  // ✅ Updated
jest.mock("./utils/helper");  // ✅ Also updated!

Examples

Jest Patterns

jest.mock("../services/api");
jest.unmock("../services/api");
jest.requireActual("../services/api");
jest.requireMock("../services/api");
jest.doMock("../services/api");
jest.dontMock("../services/api");

Vitest Patterns

vitest.mock("../services/api");
vi.mock("../services/api");

Dynamic Imports & Require

const module = await import("../services/api");
const module = require("../services/api");

Expected Behavior

1. When a file is renamed/moved via IDE operations (F2, drag-drop, etc.)
2. TypeScript should scan all files for references to the old path
3. Update all string literals that reference the file, including:
   • Standard import/export statements (already works)
   • jest.mock() and related Jest functions
   • vitest.mock() and related Vitest functions
   • require() calls
   • Dynamic import() expressions
4. Only update relative paths that actually point to the renamed file
5. Skip non-local modules (npm packages)

Workarounds

Currently, developers must:

1. Rename the file
2. Manually find all test files that mock it
3. Update each mock path by hand
4. Hope they didn't miss any

Additional Context

• This affects large codebases more severely (more mocks = more manual work)
• Common in projects with comprehensive test coverage
• Similar features exist in other IDEs (e.g., WebStorm handles this)
• Would significantly improve refactoring experience in test-heavy projects

Proposed Solution

Add an opt-in preference (e.g., updateImportsInTestFrameworkCalls) that enables this behavior. The feature should:

• Be conservative (only update simple patterns)
• Be extensible (easy to add support for new test frameworks)
• Avoid false positives (only update actual file references)
• Work with both JavaScript and TypeScript files

Alignment with TypeScript Goals

This feature aligns with TypeScript's core design goals:

1. "Statically identify constructs that are likely to be errors"

   • Outdated mock paths after file renames are errors that TypeScript can detect and prevent
   • Currently these errors only surface at test runtime, this would catch them during development

2. "Provide a structuring mechanism for larger pieces of code"

   • Enables confident refactoring and code organization without fear of breaking tests
   • Makes it easier to maintain well-structured codebases by removing friction from file reorganization

3. "Be a cross-platform development tool"

   • Enhances the IDE/editor experience across all platforms
   • Improves the TypeScript language service that powers multiple editors

4. "Preserve runtime behavior of all JavaScript code"

   • This is purely a development-time tooling enhancement
   • No changes to emitted code or runtime behavior
   • Only updates source code strings to maintain correct runtime behavior after refactoring

Affected Packages

• TypeScript Language Service
• VS Code TypeScript Extension (for preference exposure)

📃 Motivating Example

You're refactoring a large TypeScript project and decide to reorganize your file structure. You move src/api/userService.ts to src/services/users/userService.ts. TypeScript automatically updates all your imports:

// Before
import { getUser } from '../../api/userService';
// After  
import { getUser } from '../../services/users/userService';  ✅

Great! But then your tests start failing. You discover that TypeScript didn't update your test mocks:

jest.mock('../../api/userService');  // ❌ Still points to old location!

You now have to manually search through dozens (or hundreds) of test files, find every jest.mock() call that references the moved file, and update each one by hand. This is tedious, error-prone, and makes refactoring feel risky.

With this feature, TypeScript would treat mock calls the same as imports:

jest.mock('../../services/users/userService');  // ✅ Updated automatically!

Now you can confidently refactor your codebase knowing that both imports and mocks will stay in sync. Your tests keep passing, and you spend time improving code instead of hunting down broken references.

💻 Use Cases

1. What do you want to use this for?
   Large refactors and more confidence in IDE tooling.
2. What shortcomings exist with current approaches?
   This is not covered by the current version of TypeScript.
3. What workarounds are you using in the meantime?
   When moving single files have to also search for all references to that files (or forget about that and have CI failing)
   When moving folders I need to run the full suite to find where there might be file references that need a manual update.

[MartinJohns]

How would the compiler know it's a path that needs to be changed and not just a string? This would require something like #42054 first (or hardcore specific test frameworks, which would be a really bad idea).

[jcalz]

@MartinJohns

hardcore

🤘

... hardcode?