[bug] findRelatedTests misses tests, especially in multi-project setups

[paularmstrong]

Do you want to request a feature or report a bug?

bug

What is the current behavior?

Here's an absolute minimal repo that explains this same test case and can be run directly: https://github.com/paularmstrong/jest-multi-project-example

1. Clone the repo at https://github.com/paularmstrong/jest-multi-project-example
2. Run yarn to install dependencies
3. Run yarn test to ensure tests run
4. Run yarn test --findRelatedTests --listTests projects/bar/bar.js (test is a package script shortcut to jest)

Expectation

We should expect to see the following files as related in the output:

projects/bar/__tests__/index.test.js
projects/foo/__tests__/index.test.js

Actual results

Jest does not appear to resolve related changes across project configurations and we do no receive any listed tests.

Alternatively

If we run yarn test --findRelatedTests --listTests projects/bar/index.js, we do receive only the file for the direct project, bar.

projects/bar/__tests__/index.test.js

Why this is problematic

This is a problem because if we are in a sufficiently large project with many workspaces and many interdependencies, we may make a change to one file in a single workspace and expect to be able to run only the related tests for that change, but none will be run.

We could argue that we should just run all tests, but this can take too long (15+ minutes) to realistically ask people to do every time they make a change.

Environment

Environment:
  OS:  macOS High Sierra 10.13.4
  Node:  8.11.1
  Yarn:  1.6.0
  npm:  5.6.0
  Watchman:  4.7.0
  Xcode:  Xcode 8.1 Build version 8B62
  Android Studio:  Not Found

[paularmstrong]

I'm happy to try to fix this, but not totally sure where to start. It looks like potentially part of jest-resolve, but maybe jest-resolve-dependencies. There's also a slight issue that we'll need to resolve from package.json name fields as well, which looks like a new use case.

Can anyone offer some guidance for getting started?

[SimenB]

Does it make sense to say that tests are dependent across projects? Seems like a per-project thing.

If it's an issue within a single project across workspaces, I agree it should be fixed.

@cpojer thoughts?

[cpojer]

Yeah it's not perfect. Ideally this will work but not sure how we can do that properly.

[paularmstrong]

This is cross-project/package. We want to work in a monorepo and be able to test for integration failures on breaking changes without running the entire suite of tests.

[SimenB]

Might be possible to fix by following the symbolic link yarn/lerna puts in node_modules and seeing that it is changed source code since last commit?

[paularmstrong]

@SimenB I'm not sure I understand what you're saying. Do you mean that the symbolic link changed? I'm fairly certain that changing a file deep down in a module won't change the stat of the symlink.

[SimenB]

I'll have another go! I meant that when we see a require('module'), I'm not sure if we follow module if it's a symbolic link, thus pick up if its source changes.

[paularmstrong]

I meant that when we see a require('module'), I'm not sure if we follow module if it's a symbolic link, thus pick up if its source changes.

That sounds like a workable solution! I have some time next week to look in and attempt this if you're not already planning on it.

[SimenB]

Feel free!

[nstoertz]

I'm running into this problem as well with a similar monorepo setup using yarn workspaces – it would be a huge improvement if Jest could discover related tests behind symlinks.

This thread comment might be related: Add support for --preserve-symlinks

[paularmstrong]

I looked into this a bit. I think it would take a major rewrite of the jest-resolver package, since it really doesn't look at "packages" at all, so it would have to read up the tree looking for package.json, parsing that to verify, then checking if it's sym-linked in a node_modules folder.

[joaquindk]

Any progress on this? I'm encountering the exact same issue.

[github-actions]

This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions]

This issue was closed because it has been stalled for 7 days with no activity. Please open a new issue if the issue is still relevant, linking to this one.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.