--projects flag uses process.env from top level dir, not each project.

[mateodelnorte]

🐛 Bug Report

--projects flag uses process.env from top level dir, not each project. as a result, expected paths in process.env will not match runtime behavior of projects.

To Reproduce

Steps to reproduce the behavior:

Create a top level project with the following file:

module.exports = {
  projects: [
    './child-project/jest.config.js'
  ],
};

Create a child project with the following file:

module.exports = {
  name: 'child-project',
  displayName: 'child-project,
  rootDir: './',
  testEnvironment: 'node',
  modulePaths: [
    'src',
    '/node_modules/'
  ],
  collectCoverageFrom : [
    'src/**/*.js'
  ]
};

Expected behavior

process.env should be recreated for each project with process.cwd() set as rootDir for that particular project.

Run npx envinfo --preset jest

npx: installed 1 in 2.154s

  System:
    OS: macOS High Sierra 10.13.2
    CPU: x64 Intel(R) Core(TM) i7-7920HQ CPU @ 3.10GHz
  Binaries:
    Node: 9.11.1 - /usr/local/bin/node
    npm: 5.6.0 - /usr/local/bin/npm
  npmPackages:
    jest: ^22.4.3 => 22.4.3

[robin-drexler]

Agree, usually when you start the tests inside a project, you do it at the project root, hence process.cwd() is set correctly.

We were also caught off guard when we noticed that process.cwd() is not adjusted to match each project's root.

Would you consider merging a PR that addresses that? cc @cpojer

[ranyitz]

@mateodelnorte @robin-drexler If you call the jest command from an inner directory, the process.cwd() won't be the rootDir even without any projects configuration.

process.cwd() is the directory from which you invoked the node command, or in our case, the jest command. By changing that we will loose that information.

[unional]

I have the same problem as @robin-drexler
Tests in a project assume the process.cwd() is the project's root.
So when jest is executed with --projects, all of those tests fail.
We have to do path.resolve(__dirname, '../../dir') to fix the path.
That is not desirable as sometimes the code is expecting a relative path, including the tests.

[jeysal]

I disagree with changing the cwd automagically, this would be very unusual behavior and probably cause more confusion, not less. The rootDir mechanism exists exactly for the purpose of defining an anchor that is agnostic to where Jest is being run from. If there's any concrete use cases that cannot currently be covered well such as #7359, we can look into solving those in a less invasive way :)

[Andarist]

This has caught me off guard as well, I've prepared a simple repro showcasing the problem:
https://github.com/Andarist/jest-projects-cwd-repro/blob/master/package.json#L12
This is basically the same thing which @unional describes.

I would expect projects to run independently of each other - each instance/project should be independent and run exactly~ the same way as it would when jest would be run inside a particular project.

IMHO this especially makes sense as the announcement post of this feature - https://jestjs.io/blog/2017/05/06/jest-20-delightful-testing-multi-project-runner#multi-project-runner-configuration-overhaul says something like:

Here is a video of Jest running tests for React, Relay, Yarn and Jest all at the same time:

This in my head implies that those listed projects (and their jest.config.js and relative paths in tests etc) don't have to know at all about being possibly run through this feature and shouldn't have to adjust their code to accommodate for this. It should "just work".

[binaryunary]

Any updates on this?

[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 30 days.

[Andarist]

Bump for stale bot

[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 30 days.

[Andarist]

Bump for stale bot