Skip to content

Jest doesn’t respect Node resolution when looking for the CLI #5294

@gaearon

Description

@gaearon

This is related to #5119 (comment).

Our react-scripts package from Create React App depends on jest and runs it using the Node API. So jest is generally a dependency.

However, people often install top-level jest in their project (mostly because they don’t know it won’t work), and this breaks their setup with obscure errors like #5119. Their tree looks something like:

├── jest@22.0.6 
└─┬ react-scripts@1.0.17
  └── jest@20.0.4 

Ideally, top-level jest installations shouldn't break the copy of jest in react-scripts. This is a general assumption that typically holds true in the Node ecosystem: different versions of the same subdependency can coexist in different parts of the tree, and not break each other as long as you don’t mix their state.

In the case of Jest, it breaks because Jest uses <process.cwd()>/node_modules/jest-cli as the location of the CLI. Since in our project, process.cwd() is its root, Jest 22 “finds” jest-cli from Jest 20 and mistakingly uses it instead of its own copy of jest-cli:

├── jest@22.0.6 
└─┬ react-scripts@1.0.17 // <-- this is the calling code
  └── jest@20.0.4             

├── jest@22.0.6 
└─┬ react-scripts@1.0.17 
  └── jest@20.0.4 // <-- it calls Node API of this copy 

├── jest@22.0.6 // <-- but the inner copy "finds" the CLI from this copy and breaks
└─┬ react-scripts@1.0.17 
  └── jest@20.0.4

I don’t know if this is intentional. Maybe this has to do with multi-project runner? Regardless, it would be nice if Jest either supported this, or failed with a clear message when Node API of one version of Jest resolves to the CLI code of another version of Jest.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions