Make the object printing depth configurable

[grnch]

When printing objects or exceptions, Ava restricts the depth of the printed objects to 3 levels. Some libraries that like to throw exceptions with deeply nested data in them (e.g. Axios) would benefit from increasing the printing depth when debugging failing tests, but unfortunately this depth is hardcoded in Ava and it's not possible to change it by the user.

I would propose instead to tie this depth to util.inspect.defaultOptions.depth, which is a setting that NodeJS uses to control the depth of printing for console.log() and similar. Most NodeJS developers who have had to debug deeply nested objects by printing them with console.log() are already familiar with this setting, so it would come natural to use the same setting to control Ava's printing depth.

There are other ways this could be implemented, of course, for example by exposing this option as a command line argument or through some Ava-specific environment variable, but I think tying it to NodeJS's printing depth is the most practical solution. This way a NodeJS developer could kill two birds with one stone, by setting both the NodeJS and Ava printing depth in one go, rather than hunting for Ava-specific docs separately.

[novemberborn]

@grnch I like your proposal. Have you tried this PR yourself?

I think we may have to change maxDepth from a property to a getter, so that the configuration can be changed on the fly. We definitely need to ensure you can use AVA's require configuration to load a file that modifies this setting.

[grnch]

Good point, @novemberborn!

I had been changing the depth before Ava is loaded so that's why it worked for me, but using a getter like you suggested is clearly superior because then it works even after Ava is loaded.

I have changed the code to use a getter and also clamped the depth to a minimum of 3, as you suggested.

Thanks!

P.S.
You may be wondering how I was changing the depth before Ava is loaded, when the first thing the Ava CLI does is require('ava').

On my dev machine I have this env var permanently set:

export NODE_OPTIONS="-r $HOME/.noderc"

This allows me to put whatever Node initialization code I want in ~/.noderc and it always gets loaded by the Node process before anything else, regardless of how the node executable is started.

[grnch]

Is there anything I should be doing about the Windows build failure in Travis? It seems like a random failure not related to the changes in this PR.

I could change the time stamp on the commit and force push it again, to trigger another Travis build.

[novemberborn]

You may be wondering how I was changing the depth before Ava is loaded, when the first thing the Ava CLI does is require('ava').

On my dev machine I have this env var permanently set:

export NODE_OPTIONS="-r $HOME/.noderc"

This allows me to put whatever Node initialization code I want in ~/.noderc and it always gets loaded by the Node process before anything else, regardless of how the node executable is started.

Oh that's a neat trick!

Is there anything I should be doing about the Windows build failure in Travis? It seems like a random failure not related to the changes in this PR.

Yea they happen. No worries.

[novemberborn]

@grnch this looks good. But we should document it, too. Perhaps as another section in https://github.com/avajs/ava/blob/master/docs/06-configuration.md? What do you reckon?

[grnch]

Sure thing @novemberborn.

I'll write something up when I'm near a real computer again.

[grnch]

Added some docs, please let me know if the wording or location needs to be changed.

[novemberborn]

Thanks @grnch!