[Bug]: Watch fails if SL (Steam Locomotive) is installed

[dvanoni]

Version

29.5.0

Steps to reproduce

1. Install SL (Steam Locomotive); e.g. brew install sl
2. Clone my repo https://github.com/dvanoni/jest-watch-sl-bug
3. npm install
4. npx jest --watch

Expected behavior

npx jest --watch runs and prints the following message:

No tests found related to files changed since last commit.
Press `a` to run all tests, or run Jest with `--watchAll`.

Watch Usage
 › Press a to run all tests.
 › Press f to run only failed tests.
 › Press p to filter by a filename regex pattern.
 › Press t to filter by a test name regex pattern.
 › Press q to quit watch mode.
 › Press Enter to trigger a test run.

Actual behavior

npx jest --watch fails with the following message:

Determining test suites to run...

  ● Test suite failed to run

thrown: [Error]

Additional context

#13941 introduced support for Sapling which provides a command named sl. This conflicts with the sl command provided by SL (Steam Locomotive). When you have SL installed on your machine rather than Sapling, jest-changed-files fails to run properly.

Environment

System:
  OS: macOS 13.2.1
  CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
Binaries:
  Node: 18.15.0 - ~/.asdf/installs/nodejs/18.15.0/bin/node
  npm: 9.5.0 - ~/.asdf/plugins/nodejs/shims/npm
npmPackages:
  jest: ^29.5.0 => 29.5.0

[mrazauskas]

Good catch. I was looking at Sapling documentation, might be there is one more related issue on PowerShell:

Note that the name of the Sapling CLI sl.exe conflicts with the sl shell built-in in PowerShell (sl is an alias for Set-Location, which is equivalent to cd).

Reference: https://sapling-scm.com/docs/introduction/installation#windows

Seems to be sensible to check that sl is really Sapling. Perhaps sl --version could be the command for this check? It prints: Sapling [version number].

[dvanoni]

I think that would work. If you run sl --version with SL installed, you'll get the steam locomotive yet again. 😄

[tvararu]

On my system, having sl installed didn't cause the tests to fail to run; rather, determining which tests to run takes a long time now with the --watch command, about 6 seconds. The tests execute instantly when running normally. Removing it via pacman -R sl makes --watch behave as before.

Environment:

$ npx envinfo --preset jest 
  System: 
    OS: Linux 6.2 Arch Linux 
    CPU: (8) x64 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz 
  Binaries: 
    Node: 18.1.0 - ~/.asdf/installs/nodejs/18.1.0/bin/node 
    Yarn: 1.22.19 - ~/.asdf/shims/yarn 
    npm: 9.6.2 - ~/.asdf/plugins/nodejs/shims/npm 
  npmPackages: 
    jest: ^29.5.0 => 29.5.0 

[Nokel81]

Copying from my own issue (which is now closed):

Having steam locomotive installed (on macOS via brew) caused watch runs to fail with a weird error:

  ● Test suite failed to run

thrown: [Error]

after digging around it turned out that the formatting is bad (and probably should also be fixed) but that opaque error is actually the following:

Error
    at ChildProcess.spawn (node:internal/child_process:413:11)
    at Object.spawn (node:child_process:700:9)
    at execa (/Users/nokel81/repos/lens/node_modules/jest-changed-files/node_modules/execa/index.js:83:26)
    at Object.findChangedFiles (/Users/nokel81/repos/lens/node_modules/jest-changed-files/build/sl.js:104:43)
    at /Users/nokel81/repos/lens/node_modules/jest-changed-files/build/index.js:51:17
    at Array.map (<anonymous>)
    at getChangedFilesForRoots (/Users/nokel81/repos/lens/node_modules/jest-changed-files/build/index.js:50:43)
    at processTicksAndRejections (node:internal/process/task_queues:96:5) {
  errno: -63,
  code: 'ENAMETOOLONG',
  syscall: 'spawn',
  originalMessage: 'spawn ENAMETOOLONG',
  shortMessage: 'Command failed with ENAMETOOLONG: sl status -amnu /Users/nokel81/repos/lens/packages/core\n' +
    'spawn ENAMETOOLONG',
  command: 'sl status -amnu /Users/nokel81/repos/lens/packages/core',
  escapedCommand: 'sl status -amnu "/Users/nokel81/repos/lens/packages/core"',
  exitCode: undefined,
  signal: undefined,
  signalDescription: undefined,
  stdout: '',
  stderr: '',
  all: '',
  failed: true,
  timedOut: false,
  isCanceled: false,
  killed: false
}

[rmartine-ias]

I would like to suggest that fixing this issue should include displaying a more descriptive error in this case than the one it does:

  ● Test suite failed to run

thrown: [Error]

[SimenB]

/cc @vegerot

[SimenB]

We might need to revert the sapling support and figure out a better approach. The timeout suggested in #14061 seems icky to me. My own suggestion of grepping man pages or crawling the FS doesn't seem good either.