Support `.ava` cacheDir for better compatibility with Yarn PnP

[andrewzey]

Hello,

We're using Yarn 3 with PnP in our mono-repo, and find that ava is creating unwanted node_modules directories in our workspace (with node_modules/.cache/ava/failing-tests.json) This is a result of https://github.com/avajs/ava/blob/f047694d86a8ee7af2e998baf28812770e9ea71e/lib/cli.js#L256

Sometimes the existence of node_modules confuses the pnp patched executables (eg. eslint), so the mere existence of node_modules can sometimes cause issues with things working reliable.

It would be great if you supported some manner of specifying the cache directory or simply defaulted to projectDir/.ava and recommended adding .ava to the .gitignore.

Thanks!

[novemberborn]

I was thinking about this the other day actually, and yes I agree that should be an option. Placing it under node_modules by default does provide the best out-of-the box experience though.

cache is currently configurable as a boolean, I propose we add '.ava' as a valid value which would then use path.join(projectDir, '.ava') as the cache dir. All other values should result in a configuration error, I don't think we should make this super configurable just yet.

---

However this does leave us with the following code: https://github.com/avajs/ava/blob/4dc385b486176420778d368e2faca63b3d95038c/lib/worker/base.js#L210-L217

The way this could work is:

• If cache is not false, use the computed cacheDir
• Otherwise, insist on using this node_modules/.cache/ava directory

And then we'd have to document that as a caveat.

What do you think?

[andrewzey]

Wow, sorry about the incredibly delayed response!

I'm not a huge fan of polymorphic variables personally, so it seems cleaner to leave cache as a boolean and have an additional cacheDir configuration option that has an allowlist of values, starting with just ['.ava'] as you proposed and defaulting to node_modules/.cache/ava if the option isn't specified.

Would you be ok with that?

[novemberborn]

@andrewzey that's fair. Maybe tempDir would be a better name? Or overrideTempDir?

Thinking about the importFromProject function I mentioned last year, I think that should still be fine as long as this directory is within the project, and that can be validated. Though that wouldn't be necessary if it only accepts known values.