Option to silent stdout, or at least the yeoman ascii art when testing generator

[deanrad]

I want to isolate my rspec output during an 'npm test' of my generator, so I'd like an option to hide the output of yeoman during the multiple test runs. Notice, this is not npm test > /dev/null because I want mocha's output, just not the ASCII art and file list.

Sorry if this is basic, but a search for stdout/tests for yeoman revealed alot of noise about how it used to check stdout instead of fs in tests, and not an answer to how to silence it.

[SBoudrias]

Simply create a custom Environment and mock methods that are outputting content to the console (like Adapter#log).

[SBoudrias]

We've been talking about it, and I think we're OK with adding this into core. If someone want to send a PR checking the argv passed to the process for --silent and simply not logging the stuff passing in the Adapter#log methods.

That's the file needed to be modified: https://github.com/yeoman/generator/blob/master/lib/env/adapter.js

[SBoudrias]

@hemanth is assigned on this issue and should bring something up sometime :)

BTW, don't use --silent - that was a bad idea as it would break usual UI with prompts. Better implement a global flag like YEOMAN_MUTE or something similar... Up to you.

[hemanth]

@SBoudrias Sure, will work on it.

[sindresorhus]

BTW, don't use --silent - that was a bad idea as it would break usual UI with prompts

Can you elaborate?

Better implement a global flag like YEOMAN_MUTE

You mean env variable?

[SBoudrias]

I don't like the --silent as it cannot be useful for end users.

So we'd need either an env variable - or a global. IMO, a global is allright and less error prone (no chances someone mute all his yeoman generators by error).

[sindresorhus]

@SBoudrias from what I can remember from the last meeting, you too don't want globals and it should rather be built into the interface or something. Can you expand on that?

[hemanth]

There was a suggestion for this.mute() kind of implementation.

[SBoudrias]

Yeah, it might be less error prone to call this.mute() and this.unmute() method on the generator (or the UI Adapter) to manage the mute state.

This is more secure as we're sure that no dependency author that we use will one day push an update setting global.YEOMAN_MUTE = true;.

The problem with using a mute method though is that it is sometime hard to get a hold of the generator instance as it is almost always used through the Environment façade. But it is definitively doable - and should be eventually integrated in the run-context testing façade.

---

Anoter solution, maybe we could allow user to provide a stream to write to. So then, you just need to pass a mute stream - but that'd allow you to assert stuff against the outputted string buffer on the dummy stream...

[hemanth]

@SBoudrias As this issue speaks specifically for testing, should we start pawing at run-context first?

[SBoudrias]

@hemanth It is about testing, but it relate mostly to the UI Adapter module. This is where the work should be done first.

[hemanth]

@SBoudrias Was wondering the same.

[sindresorhus]

Anoter solution, maybe we could allow user to provide a stream to write to. So then, you just need to pass a mute stream - but that'd allow you to assert stuff against the outputted string buffer on the dummy stream...

I like this.

[MethodGrab]

I created a gist showing how this can be achieved until it's implemented as part of Yeoman: https://gist.github.com/MethodGrab/09f3431942ca14b6805d

[peeter-tomberg]

Muting just yeomans output isn't enough. I have a test where I invoke installDependencies with bower/npm and get output from both commands. I had to resort to overwriting the spawn command.

[SBoudrias]

@peeter-tomberg You should really not run npm and bower during your tests.

[peeter-tomberg]

@SBoudrias I really like the idea of testing if my generator outputs a valid project. I have no idea how I could check if for example my requirejs build works without having to run npm / bower.

[jgoux]

+1 for this feature.

[eddiemonge]

@peeter-tomberg that should be a separate test. The generator will create something but that something should already be something you have and thats tested. although, its often broken by things put into a generator :D

[SBoudrias]

I tag this one as actionable and hard because it is doable, but there's a lot of part missing ATM.

[fernandopasik]

Do you think it would be a good idea to add a setting for log level ?
info > warning > error

To https://github.com/yeoman/generator/blob/master/lib/util/log.js

[SBoudrias]

@fernandopasik Maybe, but that's not a feature related to this issue.

[fernandopasik]

I was thinking of it for disabling the log util on testing.

[SBoudrias]

@fernandopasik I see what you mean, but these are really differents concepts - plus a correct solution should be able to hide more the only log.

[SBoudrias]

This is now the default (only on master, not yet released) when using helpers.run(). See http://yeoman.io/authoring/testing.html

[hemanth]

👍

[fernandopasik]

nice! thanks!