Should process.cwd() be changed to the directory of the currently running test?

[sindresorhus]

Currently the cwd is the directory you execute ava in, but ava can be executed from any upper level in the project and will search down for test files, so the cwd is pretty arbitrary and useless. I want to make the cwd actually useful.

There are two options:

1. Change cwd to root of the project. (This is what gulp/grunt does)
2. Change cwd to the directory of the currently running test file. (This is what I personally prefer)

The reason I prefer the latter is that we run the test files hence IMHO the cwd is where we run it. It's like we would do: cd tests && node test.js.

Currently you have to do this to be able to load a read a test relative file:

var path = require('path');
var fs = require('fs');
fs.readFileSync(path.join(__dirname, 'foo.json'));

If we changed process.cwd() to the currently running test directory we could instead just do:

var fs = require('fs');
fs.readFileSync('foo.json');

Thoughts? Anything I'm missing?

[mdibaiee]

I think it's a good idea but I'm not sure if it has any drawbacks as I lack experience in this kind of thing.

[Qix-]

It sounds good, but it might make migrating from Mocha a bit of a pain. New projects will benefit from it; ones coming from Mocha won't.

[sindresorhus]

@Qix- Why? It will make no difference if you've already hard-coded your paths with __dirname.

[Qix-]

True. Those that haven't should be anyway.

[vadimdemedes]

👍 Also tired of join(__dirname, 'fixtures', 'shit')

[kevva]

Yeah, I like option two too because that's really what is expected. Using the project root would confuse me.

[arthurvr]

Yeah, I like option two too because that's really what is expected. Using the project root would confuse me.

Me too. 👍

[stevemao]

I think this is more intuitive for people who haven't used mocha. But would this confuse people who just learned require(./) and fs.readFile(./) as the path are relative to different base?

[sindresorhus]

But would this confuse people who just learned require(./) and fs.readFile(./) as the path are relative to different base?

That's not correct. If you start the node script from the file location they're the same. The point is that running a test is kinda like doing node test.js from the test file location.

[stevemao]

That's not correct. If you start the node script from the file location they're the same. The point is that running a test is kinda like doing node test.js from the test file location.

True, very intuitive because this is what I thought when I first used mocha :)

[jamestalmage]

I have been pretty consistently been annoyed by this "feature". Yes require(../some/path) is relative, but if I am using require - it's at the top of my test, and easy to find. If I am using cwd, well, that could be anywhere. And it's not always easy to search for:

// relies on cwd - but it isn't apparent how use my IDE's search tool to find it.
execa('node foo.js');

Moving a test that relies on child_process.exec or execa wreaks havoc since we implemented this.

Conversely paths relative to the module file are pretty easy to locate. Look for __dirname and require (./ if things get really desperate). If I am moving a test file around (and not moving some resource with it) the search and replace is pretty easy.

I would have preferred that cwd was always set to to the same directory as package.json (found via pkgUp). That has the advantage of keeping cwd consistent, even when you execute ava from a subdir, and it allows you to treat cwd as a base for creating "intra-project-absolute paths".

[sindresorhus]

@jamestalmage I agree. In hindsight, it was a bad idea with good intentions. Too bad it didn't show its downsides until much later. I've personally been bitten by this on multiple occasions too and seen some problems with it in the ecosystem. I think we should reconsider. I've never seen anyone other than me use it anyways (I've looked at a gadzillion open source AVA test files).

Some known problems this feature caused:

• Problems with Relative Paths and Tests #175
• Doesn't work with AVA tests in separate processes istarkov/babel-plugin-webpack-loaders#41
• Support NODE_PATH in forked process #531 (had to absolutify paths from NODE_PATH becuase of the cwd change)
• Normalize relative paths in babel.extends, plugins, and presets to package.json directory #707 (would resolve this issue)

@vdemedes @novemberborn @sotojuan @jedrichards @istarkov @alexbooker @MarkHerhold @KidkArolis

[novemberborn]

Relative imports are more cumbersome than relative file paths. I like setting cwd to the package.json directory, though that might be a little tricky for monorepo's.

[jamestalmage]

though that might be a little tricky for monorepo's

Not sure why it would be. Usually there is a package.json for each package in the monorepo - so it would just be relative to that. If there's not (some people auto-generate at deploy time) then you would be relative to the root package.json.

[sindresorhus]

Ok, we're going to do this.

[jamestalmage]

We could add a cwd config option to package.json

[a-s-o]

You are right, that is the default npm behaviour. Okay then that is a good
enough convention to follow. I can live with that. Thanks for the info.
On May 22, 2016 1:57 PM, "James Talmage" notifications@github.com wrote:

We could add a cwd config option to package.json

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#32 (comment)

[jamestalmage]

Another bug caused by our current behavior: dtinth/babel-plugin-__coverage__#39

We should revert this for the next release.

[KidkArolis]

What's the status of this, changing cwd to the test file location is really annoying.

[sindresorhus]

It's blocked on having a migrate script: #32 (comment) The change itself is simple.

[shinzui]

@sindresorhus I don't think the codemod should block this issue. I just started using ava and I wasted a lot of time figuring out why hapi was not loading my models correctly in the tests. I initially blamed hapi-shelf (plugin to load bookshelf models), but after tracing the code I discovered this issue and easily fixed my test to work around it.

[sindresorhus]

Yeah, let's just do the change.

It's hard to do a codemod for this correctly anyway, and I don't think it's important enough to force us to continue having surprising behavior for new users.

@avajs/core ?

[novemberborn]

👍

[wmertens]

So is anybody working on this? I'm not volunteering, just doing a "ping" 😀

[sindresorhus]

@wmertens https://twitter.com/slicknet/status/782274190451671040

[novemberborn]

Fixed by 476c653.