Add an optional debug mode to get verbose logging

[aweary]

This is just an idea I've had that might help us resolve issues quicker. I'm thinking something along the lines of debug, though we can roll our own pretty easily I think if we want to.

Essentially I think it would be great if we could inject a few console.log calls in key parts of the code path, so when we (or anyone else) are trying to isolate an issue it's easy to see what might be going on. This would be good for checking state in internal code paths when reproducing an issue, and would let us ask users to share the output for hard-to-reproduce issues.

I'm just opening this issue for a discussion on the idea, I'm not entirely sure it's either practical or useful just yet, but I'm inclined to think it's both.

A few ways we can possibly do it (edit: these ideas aren't necessarily good at all, just examples in the same ballpark):

• If possible, parse any CLI flags (though I don't think we can do that since we're not a CLI app)
• Expose an option to enable debug logging (enzyme.enableDebugging() or something)
• Export a wrapper function that does it:

import enzyme, {mount, debug} from 'enzyme'
debug(enzyme)

• Use a special environmental variable (process.env.ENZYME_DEBUG or something)

[ljharb]

I like the idea of easier debugging. I don't think I'm a fan of adding more exports if we could avoid it.

I think an env var might not make sense for this use case, since you may want to debug just one test, while running with the whole suite, etc.

What if we had shallow.debug() and mount.debug() (and render.debug()), for the top-level only, that enabled debug mode for that wrapper?

[aweary]

@ljharb Yeah I was just spitballing, none of my suggestions seemed ideal, just a ballpark of what I'm envisioning. I think top-level methods like shallow.debug() would be cool. Would the debug call toggle the debugging on and off? So you'd just do something like

shallow.debug(); // turns it on
const wrapper = shallow(<App />)
// do wrapper stuff here
shallow.debug() // turns it off

[ljharb]

no - i'd think debugging would be permanently on for that wrapper. More like shallow.debug(<App /) than a globally stateful call.

[aweary]

Oh I see what you mean now, so shallow.debug() would basically wrap shallow() and enable debugging for the returned wrapper?

[nfcampos]

shallow.debug() might be confused with wrapper = shallow(...); wrapper.debug()

[ljharb]

@Aweary yes. @nfcampos naming obv subject to debate, if the approach (a different wrapper method that's attached to the exported wrapper method) seems sound.

[aweary]

I could definitely see how it might be confused, but I'm not sure it's entirely a big deal. It seems like a mistake you'd only make once that would be pretty obvious, but maybe I'm biased and assuming too much.

So far I like the idea of having a top-level method that returns a wrapped instance with debugging enabled most. Since most traversal methods have access to the this.node we could tag an internal debug flag onto that? I don't think adding a clearly unique flag for internal consumption should be a problem.

[ljharb]

At this point, I think this would be best as an adapter option.