np
np copied to clipboard
sindresorhus
Verbose mode
Hello folks!
I was wondering whether it is a good idea to introduce a --verbose command line argument that dumps stdout and stderr along.
I have naively did:
streamToObservable(cp.stdout.pipe(split()))
.forEach(chunk => {
console.log(chunk); // only the lines containing "hello" - and they will be capitalized
});
streamToObservable(cp.stderr.pipe(split()))
.forEach(chunk => {
console.log(chunk); // only the lines containing "hello" - and they will be capitalized
});
while debugging but I haven't put too much time (just wanted to see what was happening).
What do you think?
Debugging purposes, understanding why things are failing and be less opaque. It would be opt-in so no change in current behavior.
What specific problem are you trying to solve? In what situation could you have needed it? We don't add options lightly, so there should be clear benefits and use-cases.
The npm publish command was hanging and was not able to understand what was going on because the Observable was still awaiting for things to finish.
Thanks to the --verbose parameter I would have been able to understand what the problem was without having to debug np.
@sindresorhus In the case of npm publish, could we add a prerequisite check that checks of the user is signed in and everything is setup correctly?
@arichiardi I'm not sure if verbose would have helped you in that case as it would still have hung because it was waiting for stdin input. We already stream stdout/stdout in the task list.
I am sure that it helped, because I basically did change the streaming target of the child observables and saw what was going on 😀
I respectfully think your arguments should be more specific and not just distrust what the other party is trying to explain.
I will explain you way it was failing: the bug was neither in np nor in listr. The absence of the output actually led me to think it was. That is not a bug, but a missing feature for improving the UX of your tool, hence the open issue.
It was weird 😀. So I have a scripts section in my package.json that contains publish which basically runs np. Funnily enough, np calls npm publish, which in turn calls the whole thing all over again.
You can try it now. There is no way, a part from a --verbose flag to see what is going on clearly. Even attaching a debugger is confusing 😀
npcallsnpm publish, which in turn calls the whole thing all over again.
We could mention this problem in the readme, but the issue is mainly configuration-related.
@sindresorhus In general, I think that in many cases you prefer having extensive logging than having to duck-debug weird issues that involve many different modules and steps. What we could do is save a log file (e.g. .np-error.log) in case publishing fails, which would contain the complete log of the entire publishing process. np has grown quite a bit over the last few months, and I think that this feature would be very helpful for debugging, triaging and reporting issues.
