Skip to content

Fix: Use correct Jest config per-package in monorepo optimizations#1993

Open
mohammedahmed18 wants to merge 2 commits intomainfrom
fix/monorepo-jest-config-per-package
Open

Fix: Use correct Jest config per-package in monorepo optimizations#1993
mohammedahmed18 wants to merge 2 commits intomainfrom
fix/monorepo-jest-config-per-package

Conversation

@mohammedahmed18
Copy link
Copy Markdown
Contributor

Problem

In --all mode with monorepos, test_cfg.js_project_root was set once based on the first file and reused for all functions. When optimizing functions from different packages (e.g., worker after server), Jest would run with the wrong package's config, causing "Cannot find module" errors due to incorrect moduleNameMapper resolution.

Root Cause

  • optimizer.py:531 calls setup_test_config() once, setting js_project_root
  • This was then passed to run_jest_behavioral_tests() for ALL functions
  • In budibase monorepo: optimizing packages/worker/src/tenants.ts used packages/server's Jest config

Solution

In run_jest_behavioral_tests(), run_jest_benchmarking_tests(), and run_jest_line_profile_tests():

  • Detect the correct package root from the test file location
  • Override project_root only when it points to a different peer package
  • Preserve behavior for external test files and non-monorepo projects

Impact

  • Affected: 25/46 optimization runs (~54%) with "Cannot find module @budibase/backend-core"
  • Trace IDs: 02f0351a-db89-4ebc-a2e6-c45b19061152 and 24 others
  • Target: budibase monorepo (packages/server vs packages/worker)

Testing

  • ✅ Added regression test: test_monorepo_project_root_bug.py
  • ✅ All 316 JavaScript tests pass
  • ✅ External test files still work correctly
  • ✅ Linting and type checking pass

Files Changed

  • codeflash/languages/javascript/test_runner.py - Fix project root detection in 3 locations
  • tests/test_languages/test_monorepo_project_root_bug.py - New regression tests

In --all mode with monorepos, test_cfg.js_project_root was set once based on
the first file and reused for all functions. When optimizing functions from
different packages (e.g., worker after server), Jest would run with the wrong
package's config, causing "Cannot find module" errors due to incorrect
moduleNameMapper resolution.

**Root Cause:**
optimizer.py:531 calls setup_test_config() once, setting js_project_root.
This was then passed to run_jest_behavioral_tests() for ALL functions,
even those in different monorepo packages.

**Fix:**
In run_jest_behavioral_tests(), run_jest_benchmarking_tests(), and
run_jest_line_profile_tests(), detect the correct package root from the
test file location when the provided project_root points to a different
peer package.

**Impact:**
- Affected 25/46 optimization runs (~54%) with "Cannot find module" errors
- Trace IDs: 02f0351a-db89-4ebc-a2e6-c45b19061152 (and 24 others)
- Target: budibase monorepo (packages/server vs packages/worker)

**Testing:**
- Added regression test: test_monorepo_project_root_bug.py
- All 316 JavaScript tests pass
- Verified external test files still work correctly

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
@claude
Copy link
Copy Markdown
Contributor

claude bot commented Apr 4, 2026

Claude finished @mohammedahmed18's task in 3m 19s —— View job


PR Review Summary

  • Triage PR size — SMALL (38 lines production code)
  • Lint and typecheck — ruff format fix committed (e49b58e7)
  • Resolve stale threads — none found
  • Code review
  • Duplicate detection
  • Summary comment
  • Check optimization PRs — none open

Prek Checks

Three multi-line if conditions violated ruff's formatting style. Auto-fixed and pushed as commit e49b58e7.

Mypy: 7 pre-existing errors in test_runner.py (unrelated subprocess.run overload and type-arg issues). No new errors introduced by this PR.


Code Review

The core fix is correct. The root cause (stale project_root used across packages in --all mode) is real and the detection logic (same parent directory heuristic + package.json check) is sound for the budibase-style flat monorepo layout.

Issues found:

1. Undocumented second fix (line 389)

if base_config_path and base_config_path.suffix != ".ts":

This is a separate fix for TypeScript Jest configs (.ts files can't be require()'d from CommonJS). It's not in the PR title, description, or body. It deserves a mention and ideally its own test.

Fix this →

2. Code duplication — same block repeated 3× (medium)

The monorepo detection block is copy-pasted identically into run_jest_behavioral_tests, run_jest_benchmarking_tests, and run_jest_line_profile_tests. This should be extracted into a small helper, e.g.:

def _resolve_monorepo_project_root(test_files: list[str], project_root: Path | None) -> Path | None:
    if test_files and project_root:
        detected = find_node_project_root(Path(test_files[0]))
        if (detected and detected != project_root
                and (detected / "package.json").exists()
                and detected.parent == project_root.parent):
            return detected
    elif project_root is None and test_files:
        return find_node_project_root(Path(test_files[0]))
    return project_root

Fix this →

3. Regression test doesn't exercise the fixed code path (medium)

test_run_jest_uses_correct_cwd_when_project_root_is_wrong only calls find_node_project_root — it never actually invokes run_jest_behavioral_tests. The actual branch that was fixed (if test_files and project_root:) is untested. A proper regression test should mock subprocess.run and assert the cwd passed to Jest matches the correct package root, not the stale project_root.

Fix this →

4. Missing .resolve() in test fixture paths

Per tests/testing.md: "Always call .resolve() on Path objects before passing them to functions under test." The test does:

server_root = find_node_project_root(server_file)  # missing .resolve()

Fix this →

5. Peer-packages assumption may be too narrow (low)

detected_root.parent == project_root.parent only handles flat monorepos (all packages at the same depth). Nested packages (e.g., packages/backend/worker vs packages/server) would silently fall through without correction. Consider using _find_monorepo_root to check if both roots share the same monorepo root instead.


Duplicate Detection

No duplicates detected. The detection block is tripled within the same file (flagged above as code duplication) but not duplicated across modules.


Last updated: 2026-04-04
| Branch

Co-authored-by: mohammed ahmed <mohammedahmed18@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant