Repository navigation
node:test logs verbose feature #43574
Description
Activity
I think this could be kind of an interesting feature. Although, I'd suggest adding a
--silentto hide logs as it wouldn't have to be a breaking change. What do you think?cc @benjamingr
@ErickWendel what logs would
--silentmute?@ErickWendel what logs would
--silentmute?when we run node --tests we see the node tap output right? the --silent would be used on CI and actually omit all logs so if everything is going right it shouldn't show anything and exit with code 0
Hello @MoLow and @ErickWendel when you run jest test and you put the flag --silent=false, you can see all the logs in all levels in the test console. In this case in the node:test api you cant enable the logs, you only can view the results of the execution.
@nodejs/test_runner @cjihrig
Reacted by Moshe AtlowI don't hate the idea of a quiet mode, but I do have two thoughts:
- If we figure out reporters, we could theoretically have a "quiet" reporter instead of this other mode of operation.
- Since the test runner is part of Node core, we need to balance adding functionality with not adding a ton of new CLI flags to core, and I'm not sure this is worth adding a new flag to core.
Reacted by Moshe Atlow, Jordan Harband, Matías L, Julian Gruber, Erick Wendel, Lucas Santos, Benjamin Gruenbaum, Tobias Nießen and Kieran Mannthe --silent would be used on CI and actually omit all logs so if everything is going right it shouldn't show anything and exit with code 0
the tap output is still useful in the CI in case of a failure - users are usually interested at the specific failing test details
if we figure out reporters, we could theoretically have a "quiet" reporter instead of this other mode of operation.
+1 on that, also reporting to a file instead of stdout will be much easier and might solve this usecase
Since the test runner is part of Node core, we need to balance adding functionality with not adding a ton of new CLI flags to core, and I'm not sure this is worth adding a new flag to core.
this is probably out of scope - but we might want to introduce some kind of a
.testrcfile - for allowing configuration of the test runner (what reporters to use, concurrency etc), can be cleaner than adding lots of flagsthis is probably out of scope - but we might want to introduce some kind of a .testrc file - for allowing configuration of the test runner (what reporters to use, concurrency etc), can be cleaner than adding lots of flags
+1 on that, it would greatly help sharing configuration outside of the project, although I see #44241 has already been implemented
Another thought on that would be to check the
NODE_ENVfor whether you're running the app ondevelopment(as those are quite common) if you're running intest,production, or anything other thandevelopmentthenconsole.logswould be suppressed, otherwise, they'd be shown.I am strongly -1 to using
NODE_ENVfor anything in the test runner.Reacted by Moshe Atlow, Benjamin Gruenbaum, Julian Gruber, Erick Wendel, Lucas Santos, Alex Yang, Vladimir Grenaderov, Taylor Beseda and StevenI am strongly -1 to using NODE_ENV for anything in the test runner.
Any particular reason? Just curious on the drawbacks that I might not have thought 😅
A few reasons:
- Despite popularity,
NODE_ENVis an anti-pattern, especially when the default value is not production. I've seen multiple apps running in production without settingNODE_ENVproperly, so their performance was not as good as it could/should have been. - This is a test runner, so I'd expect
NODE_ENVto be'test'or'development'all the time.
Reacted by Moshe Atlow, Julian Gruber, Lucas Santos, Jordan Harband, Alex Yang, Josh Junon, Taylor Beseda and Steven- Despite popularity,
I see! Thanks for the explanation.
I don't see any usage of
NODE_ENVin the nodejs source code. Only in npm and third-party libraries.
So -1 on this, because I think nodejs runtime shouldn't rely on any environment variables, this will make users hard to debugNot only console.log, I'm using
util.debugLog, but it also cannot display to the console or somewhere else@himself65 to be fair,
debugLogalready relies onNODE_DEBUG(akin todebug).
What is the problem this feature will solve?
This feature solve the problem to turn on and turn off the logs (info/warn/error/log/etc) in the testing runner (node 18)
What is the feature you are proposing to solve the problem?
Add a simple flag in the node commands that allow to turn on the logs in combination of the next command:
node --test --verbose with the testing runner in node 18.
What alternatives have you considered?
No response