Skip to content

Allow specifying jest's cacheDirectory #2687

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
nerfologist opened this issue Jun 29, 2017 · 7 comments
Closed

Allow specifying jest's cacheDirectory #2687

nerfologist opened this issue Jun 29, 2017 · 7 comments
Milestone

Comments

@nerfologist
Copy link

Hi,
this proposal is related to issue jestjs/jest#3705 (jest cache is not handled correctly upon moving files from point A to point B. This eventually causes coverage information to be displayed incorrectly).

For this reason, it would be nice to have a way to clear the jest cache manually when required. In order to do that, it would be useful to have a way to set the cache directory.

This is possible in Jest by setting the cacheDirectory config option in package.json (or from the command line). Unfortunately, in an application created with create-react-app, this config option is among those which cannot be overridden:

Out of the box, Create React App only supports overriding these Jest options:

  • collectCoverageFrom
  • coverageReporters
  • coverageThreshold
  • snapshotSerializers.

These options in your package.json Jest configuration are not currently supported by Create React App:

  • cacheDirectory

Without being able to set cacheDirectory, the cache files are created in a random-looking temporary directory such as /private/var/folders/zj/112vf5bj0js_hx6l9ntz3w780000gn/T/jest_dx (at least on my Mac Os X Sierra machine).

I think it would be useful to be able to set cacheDirectory to something more predictable, such as ./node_modules/.cache/jest, or even ./.cache/jest.

What do you think?

Thanks in advance for this awesome tool!

@gaearon
Copy link
Contributor

gaearon commented Jun 29, 2017

I think the right thing to do would be to fix it in Jest.

@JReinhold
Copy link

JReinhold commented Jul 3, 2017

I have another use-case for setting the cacheDirectory.

We use CircleCI to test our builds, and in other React projects we've seen speedups of up to 60% when CircleCI starts to cache the jest cache between each build.
This is trivial to achieve when we manually set jest's cache directory, but right now I have to find a way to cache jest's default directory in between my CircleCI builds.

Similar to issue facebook/jest #1608, where the recommended solution is to configure the cache directory manually.

@gaearon
Copy link
Contributor

gaearon commented Jul 3, 2017

We already store Babel cache in node_modules/.cache so we might as well do the same for Jest.
But I'd love to learn more about:

We used to store it inside of Jest but it was always a huge issue to people

Can you research why it was an issue before? cc @cpojer

@cpojer
Copy link
Contributor

cpojer commented Jul 3, 2017

Watchman picks it up, it has to be ignored globally, I managed to publish some private cache to npm at some point, all these kinda things. Since we moved it to tmp, we didn't have a problem with it at FB.

@JReinhold
Copy link

I'm sorry, I tried doing some detective work on Google and StackOverflow, but I can't really elaborate more on the issue than what @cpojer has already described.

I can only say that I've stored the cache in <PROJECT_ROOT>/.tmp/ in a previous project without problems. Although that was a React Native project, so I'm not even sure the comparison is valid at all.

@gaearon
Copy link
Contributor

gaearon commented Jan 8, 2018

I'd be okay taking a PR that enables this configuration.

@gaearon
Copy link
Contributor

gaearon commented Jan 14, 2018

Closing for lack of interest.

@gaearon gaearon closed this as completed Jan 14, 2018
@lock lock bot locked and limited conversation to collaborators Jan 20, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants